UTILIZER EQUIPMENT DATA MANAGEMENT SYSTEM

专利摘要:
Apparatus data management system (100) (1), the system comprising - a central data platform (4) for interconnecting a plurality of communication boxes (5), each communicating communication box ○ a plurality of devices (1) arranged locally in a predefined physical environment; and ○ being configured to go back to the central data platform (4) with data associated with said plurality of devices; an analyzer module (13) for mega-data configured to analyze the data recorded in the central data platform (4) so as to generate correlations, trends, and / or predictions; an interface (8) according to a service architecture oriented mode for the provision of the analysis results.
公开号:FR3031205A1
申请号:FR1463496
申请日:2014-12-31
公开日:2016-07-01
发明作者:Malo Jennequin
申请人:Bull SA；
IPC主号:

专利说明:

[0001] The invention relates to a data management system, in a multi-vendor and multiservice context, for managing the data of a set of objects or equipment connected to a computer. network. With the emergence of the Internet of Things, more and more services are being offered to individuals and professionals, such as services relating to homes or offices including connected objects. For example, in a home automation context, it is possible via equipment comprising sensors and actuators, deployed in a house and connected to a network, to provide services ensuring: 15 - domestic comfort, for example allowing to automate and control equipment from a fixed station, or remotely for example via a remote control, a laptop, a telephone; o automate actions through geolocation, for example open a portal, turn on the heating, manage lighting, activate an alarm; - energy savings, allowing o to avoid waste by eliminating unnecessary expenses; o to ensure an optimal level of comfort; 25 o control electricity consumption by optimizing for example heating, lighting or hot water production; - home protection by systems to o supervise frail, elderly or disabled persons; o monitor children to prevent any risk of accident; o detect intrusions, falls, water leaks, and sound an alarm if any.
[0002] However, the existing systems offering these services have various disadvantages or limitations: the actors of the Internet of Things are numerous and varied, as examples: manufacturers, publishers, distributors, telecommunications operators, energy companies, insurers. Each of these actors generally builds an offer based on a number of equipment, sensors and / or actuators selected from another (other) supplier. This therefore requires close collaborative work between the concerned actor and the research and development teams of the determined supplier, with a view to proposing a product integration solution. Some Internet of Things players, for their part, offer a wide variety of connected devices, while remaining their own developer of user services. Although collaboration with research and development teams is then facilitated, these actors remain unable to integrate equipment from separate suppliers in their platforms, which remain owners. More generally, all of the solutions integrated into the same platform are currently solutions that integrate a priori equipment vendors determined. The possibilities of retrospective integration of equipment, sensors and actuators remain very limited. These possibilities are furthermore dependent on the characteristics of the supplier solutions that have to evolve, for example dependent on the proprietary protocols employed and their evolutions. Therefore, these solutions lack adaptability; the connected equipment, sensors or actuators of the systems offering services, are generally proprietary, that is to say relate to the same seller / supplier. A communication box, commonly referred to as "box", then interconnects the various equipment, sensors or actuators with service platforms or external networks. Thus, for different services provided by different sellers, the user is often obliged to use a communication box by vendor, which implies ergonomic problems in his home; - Proprietary equipment connected to the same communication box is heterogeneous and commonly relies on different non-standardized communication protocols. Therefore, in a multi-vendor context, if a device changes, its communication protocol also changes frequently. This implies a dependence of the box vis-à-vis the equipment, the box must then support the new protocol of the equipment, that is to say, guarantee access and exchange with this new equipment; 10 - several sellers can be brought, with their agreements, to offer separate services on the same box. Multi-vendor services are then run in parallel on the same box. However, this does not imply sharing all the data or resources associated with these services, the sellers not wishing, for example, to share confidential data. In addition, the execution of a service must be able to take place independently of the other services executed in parallel, for example independently of the memory resources used by other user services.
[0003] Thus, the malfunction of a service must not impact the resources of neighboring services. There is therefore a need for "partitioning" services performed in parallel on the same box, particularly for user services from different vendors; - Providers in charge of developing user services may want to access a set of reliable data in order, for example, to design residential services without necessarily being an equipment supplier. In a multi-vendor and multiservice context, it is particularly appropriate to deploy services on a platform, the latter guaranteeing both access to reliable data from separate vendors' equipment, and ensuring the communication as well as the control of data. these equipments. Generally, equipment suppliers 35 offer equipment with the possibility of remote control, access to their data, set up scenarios, and support protocols (eg KNX, Zigbee, 3031205 4 Z-Wave). However, the services offered by these suppliers are limited to equipment only, or concern only one supplier / seller. The service provider must therefore be an equipment supplier and does not have access to the data generated by the multi-vendor equipment. The equipment supplier therefore has data of very limited scope, greatly limiting the information useful for the development of a user service. In particular, there is currently no platform for grouping a multi-vendor and multiservice data set, in order to guarantee centralized access to these data, management of multi-vendor equipment and the setting up of scenarios. multiservices (eg start heating below a threshold temperature). The realization of such a platform involves technical problems concerning the securing of data, their access as well as the management of exchanges between such a platform and the equipment. The present invention aims to address the aforementioned problems.
[0004] To this end, it is proposed, according to a first aspect, a data management system relating to equipment, this system comprising a central data platform for the interconnection of a plurality of communication boxes, each box of 25 communication o interconnecting a plurality of locally arranged equipment in a predefined physical environment; and o being configured to return data associated with said plurality of devices to the central data platform; a mega-data analytics module configured to analyze the data recorded in the central data platform to generate correlations, trends, and / or predictions; An interface according to a service architecture oriented mode for the provision of the analysis results. This system further includes a service architecture-oriented interface for receiving data to the central data platform. In one embodiment, these data destined for the central data platform come from social networks. According to various embodiments, the mega-data analytics module is further configured to classify, according to a predefined data topology, the data recorded in the central data platform; - to anonymize the data stored in the central data platform so as to preserve their confidentiality.
[0005] Other objects and advantages of the invention will become apparent from the description of embodiments, given hereinafter with reference to the accompanying drawings in which: - Figure 1 is a diagram showing a multi data management system vendors and multi-services according to one embodiment; FIG. 2 is a data modeling relational diagram according to one embodiment; FIG. 3 is a class diagram of a node of the data modeling relational schema according to one embodiment; FIG. 4 is a class diagram of another node of the data modeling relational schema according to one embodiment; Figure 5 is a topological diagram describing another node of the data modeling relational schema according to one embodiment; FIG. 6 is a topological diagram describing another node of the data modeling relational schema according to one embodiment; Figure 7 is a topological subset describing another node of the data modeling relational schema according to one embodiment; FIG. 8 is a diagram illustrating the elements relating to a service according to one embodiment; Figure 9 is a diagram illustrating the relationship between different services according to one embodiment; FIG. 10 is a figure illustrating an action manager according to one embodiment; FIG. 11 illustrates a data flow relating to an action consumer according to one embodiment; FIG. 12 illustrates the establishment of a tunnel, for a communication mechanism between a communication box and a proxy according to one embodiment; FIG. 13 illustrates remote handling of the communication box for the communication mechanism with a proxy according to one embodiment; FIG. 14 illustrates the transmission of an action request to an actuator associated with an equipment for the communication mechanism with a proxy according to one embodiment; FIG. 15 illustrates the feedback of a measurement of a sensor 25 associated with equipment for the communication mechanism with a proxy according to one embodiment; FIG. 16 illustrates the establishment of a connection between a central platform and a communication box for a communication mechanism implementing UPnP protocol 30 according to one embodiment; FIG. 17 illustrates the remote handling of the communication box for the communication mechanism implementing the UPnP protocol according to one embodiment; FIG. 18 illustrates the transmission of a request for action to an equipment associated actuator for the communication mechanism implementing the UPnP protocol according to one embodiment; FIG. 19 illustrates the feedback of a measurement of a sensor associated with an equipment for the communication mechanism implementing the UPnP protocol according to one embodiment; FIG. 20 illustrates the establishment of a connection between a central platform and a communication box for a communication mechanism implementing the XMPP protocol according to one embodiment; FIG. 21 illustrates remote handling of the communication box for the communication mechanism 10 implementing the XMPP protocol according to one embodiment; FIG. 22 illustrates the transmission of an action request to an actuator associated with an equipment for the communication mechanism implementing the XMPP protocol according to one embodiment; FIG. 23 illustrates the feedback of a measurement of a sensor associated with an equipment for the communication mechanism implementing the XMPP protocol according to one embodiment; FIG. 24 illustrates the establishment of a connection between a central platform and a communication box for a communication mechanism implementing the STUN protocol according to one embodiment; FIG. 25 illustrates remote handling of the communication box for the communication mechanism implementing the STUN protocol according to one embodiment; FIG. 26 illustrates the transmission of an action request to an equipment associated actuator for the communication mechanism implementing the STUN protocol according to one embodiment; FIG. 27 illustrates the operation of a software platform 30 according to one embodiment; FIG. 28 illustrates an example of distribution of the elements of the software platform according to one embodiment; FIG. 29 illustrates the realization of the unified access structure according to one embodiment; FIG. 30 illustrates an operation of the unified access structure with equipment operating in a synchronous mode according to one embodiment; FIG. 31 illustrates an operation of the unified access structure with equipment operating in an asynchronous mode according to one embodiment. Fig. 1 is a diagram showing a multi-vendor and multi-service data management system 100 according to one embodiment. The data management system 100 is interfaced with the following entities: one or more equipment 1 disposed locally in a predefined physical location or environment, for example in an indoor environment such as a home or office. Equipment 1 is provided (arrow 3) by equipment suppliers 2, that is to say technology manufacturers. Advantageously, the equipment 1 comprises sensors and makes it possible to go back to a central data platform 4, via a "box" type communication box 5, with quantifiable data and / or associated state changes. measurements or status reports of said sensors (eg temperature measurement, position of a switch associated with a lighting system). To do this, the equipment 1 is connected to the communication box 5 via a wired or wireless network. The communication box 5 exchanges, locally or remotely, data with the central data platform 4, via another network, for example the Internet. In addition, the equipment 1 25 can perform physical actions (eg turn on the heating) via one or more actuators. Typically, an actuator performs an action following receipt of an action notification communicated from the communication box 5. The data exchanged between each equipment item 1 and the communication box 5, for example data transmission measured by the sensors or action notifications intended for an actuator of a device 1, are communicated according to one or more protocols. 6 symbolized by a double arrow. By way of example, a protocol 6 associated with a device may be a KNX, Zigbee, Wifi or Z-wave protocol; User services providers, typically players in the Internet world, developing and providing the user with user services targeted to a particular domain, for example services relating to security, comfort, or welfare. Advantageously, these user service providers 7 have a complete business logic and perform user services based on data and basic services, provided prior to the central data platform 4. Advantageously, these providers 7 of 10 user services interface (arrow 8) with the central data platform 4 in a service architecture oriented mode, commonly referred to as SOA (acronym for "Service Oriented Architecture"); data providers 9 of the Internet world, providing, for example, meteorological data, news or social networks, to trace quantifiable data (eg weather measurements) or data of change of state. Advantageously, these data providers 9 interface (arrow 10) also with the central data platform 4 in an SOA service-oriented mode; - Basic service providers 11, actors of the internet world, providing basic services to the central data platform 4 (eg implementation of a notification service), these services being used by the user service providers 7, such as: "basic" services to carry out user services. Advantageously, these basic service providers 11 interface (arrow 12) also with the central data platform 4 in an SOA service oriented mode. In addition, any provider may optionally play a plurality of roles. For example, a data provider 9 may also be an equipment provider 2 and a user service provider 7.
[0006] Advantageously, the data management system 100 takes into account several dimensions: a multi-service dimension, that is to say integrates and proposes a plurality of types of user services, for example home automation and e-health ; a multi-vendor dimension, the equipment 1 supported by the system 100 may come from different manufacturers, and include characteristics specific to each of these manufacturers; a multi-level dimension, the data and the basic services can be provided: at the level of the equipment 1 by at least one communication box; o at the level of the data management system 100. For example, the system 100 performs an analysis of data provided by equipment 1 or data providers 9, these data possibly being abstracted beforehand to preserve their confidentiality. The results of the analysis then allow the system 100 to provide correlations, trends, predictions on these data; 20 o at the level of the user service providers 7, by the provision via the system 100 of data management (possibly abstract beforehand), trends / correlations relating to this data, and basic services to carry out the user services. To do this, the data management system 100 comprises the following entities, the operation of which will be detailed in greater detail later: the box of communication of the "box" type that can, for example, be deployed at the home of the user. This box makes it possible to interconnect one or more devices 1 via a wired or wireless link according to a predetermined protocol that is a function of the manufacturer (eg TCP / IP, ZigBee, Wifi) and to exchange data with the central data platform 4.
[0007] Advantageously, the communication box 5 allows the management of multi-vendor equipment 1, that is to say, supports and manages a plurality of protocols, as well as the identification and isolation of the data / resources of each of the devices. services performed in parallel in this box; o guarantee secure and reliable communication with the central data platform 4; O o provide the data center platform 4 exploitable multi-vendor data from the sensors of the equipment 1; receiving notifications from the central data platform, relating, for example, to a remote start for administration or sending of action (s) to be executed by one or more equipment 1 to which it is interconnected; the central data platform 4 concentrating and federating all the data coming from the communication boxes 15 deployed in various places (eg homes, offices), the data coming from the data providers, as well as the basic services necessary for the development of new user services. Advantageously, the central data platform 4 is configured to: o provide a centralized and organized storage of data, the data can for example be organized according to their structure: raw data from the sensors, consolidated, aggregated and / or abstract . By way of example, for reasons of confidentiality, raw data sent back from a sensor can be formatted / structured by the central data platform 4 in a pivot format, making it possible to abstract these data, such as a type format. XML; from their origin: data from the sensors, sent back by the equipment 1 or from an external data provider 9; their right of access and identification: a user service provider may have limited access to a certain type of data; O ensure the segregation of data and basic services. Advantageously, this makes it possible, in a multi-vendor environment, to make available to a set of providers 7 of user services the rich and multiple nature of the data, and in a manner controlled by identification and authentication of the consumers of this data, here the providers 7 of user services; 10 ^ a restriction of accessibility to data / services, in accordance with the rights of consumers of such data; monitoring of the use of data / service consumption for each of these consumers; o ensure the confidentiality of data, for example, an anonymization of data via an abstraction method (eg abstraction of data in the same pivot format); o federate a set of basic services provided by the basic service providers, so as to have a global, coherent and controlled ecosystem; o provide the basic services to the user service providers 7 for the realization of said services, as examples, of the workflow type services 25 (commonly referred to as "workflow"), or the processing services of complex events CEP (acronym for "Complex Event Processing"); o guarantee secure and reliable communication with the different communication boxes 5; O provide usable data to an analytics mega-data module 13 called "Big Data Analytics"; an analytic mega-data module 13 (called "Big Data Analytics") configured to analyze the data of the central data platform 4 with which it is interfaced. The mega-data analytics module 13 makes it possible, in particular, to establish, and then make available to the user service providers 7, correlations, trends, and / or predictions of the data 3031205 13 recorded in the central data platform 4, by generating analysis reports ("reporting" services). Advantageously, the data from the central data platform 4 are identified and then classified according to a pre-established data topology. By way of example, FIGS. 2 to 7 illustrate a pre-established data topology embodiment, according to a unified modeling language, UML, the acronym for "Unified Modeling Language", this topology is detailed later. According to various embodiments, a data topology is used by the central platform 4 or the Big Data Analytics 13 module to classify the data recorded in the central data platform 4. Thus, in one embodiment, a data topology describing a data classification pattern is prerecorded in the central data platform, and used by the latter to classify the data. By way of example, the central data platform 4 is configured to identify the source of a data, for example a measurement resulting from a sensor by reading its sound at the head, and then according to its source to classify it according to the topology. prerecorded. In another embodiment, a pre-established topology is prerecorded in the mega-data analytic module 13. The latter is then configured to order / structure the data of the central data platform 4 in a database of this platform (eg a NoSQL database). In another embodiment, the functions of the central data platform 4 and the mega-data analytic module 13 are realized by a single and unique module (not shown). Advantageously, the data recorded / manipulated in the central data platform 4 is in the form of business objects, that is, data structures relating, by way of example, to devices 1, objects, places or entities interfacing and exchanging data with the data management system 100. In one embodiment, in a home automation context, the data management system 100 comprises the following business objects: "Home": each home is associated with a unique identifier on the platform, identified by a type (ex: particular, 3031205 14 company) and associated with its own characteristics (boxes, equipment, sensors, actuators); "Box": This object designates any communication box 5 encapsulating services / functionalities and supporting different communication protocols. At each home, at least one communication unit 5 is associated, that is to say a "box" object, this object comprising a unique identifier; - "Equipment", each equipment 1 is installed in a home, is connected only to a single box 5 of 10 communication, and includes a unique identifier; - "Sensor", a sensor makes it possible to measure a physical quantity or to identify a change and is associated with only one equipment 1; - "Actuator", an actuator makes it possible to trigger an action 15 following an event and is associated with a single item of equipment 1. Moreover, in order to classify and discriminate the data recorded in the central data platform 4, as explained above, a pre-established data topology is implemented.
[0008] An exemplary topology is shown in Figure 2 as a tree structure consisting of nodes and edges, in accordance with the UML standard. This tree includes, here, a root node "Root", the other nodes relating to the entities of the platform. More particularly, each node of this model is associated with a class diagram, which will be described later. Advantageously, the relationship between each entity is represented by a stop (link) and a cardinality. The cardinalities of FIG. 2 are here proposed by way of purely illustrative example. It can be seen, for example, in this figure that the cardinality of the stop connecting the node "Root" to the node "Entity" here is "1. *", which means that the node "Root" comprises one or more instances of class described in the "Entity" class. The arrows in this figure illustrate the dependencies between the different nodes, the nodes of this model being the following: - node "Entity": this node designates a place, a person, an animal; - node "Data": this node represents the data of the central data platform 4 The sources of this data are the sensors, the aggregated data of a sensor, the data from the data providers 9 (ex: data 5 environmental, data from social networks, or more generally any internet data); - "Infrastructure" node: this node describes the various objects relating to the home environment, such as the objects "Box", "Equipment", "Sensor", "Actuator" 10 previously mentioned. There are two types of infrastructure: managed or unmanaged. The term "managed infrastructure" denotes any object associated with a communication box, and more generally any connected object, that can exchange data with the central data platform 4 and that can be supervised by the management system 100. data. Thus, a managed infrastructure is inventoried in the data management system 100 and configurable under the responsibility of this system. - By contrast, unmanaged infrastructure means any object or equipment 1 that can not be supervised by the data management system 100. Such an infrastructure remains however inventoried, that is to say, known data management system 100; "Actor" node: such a node designates the actors of the platform. An actor may be a user of the platform, a user service provider 7, a equipment supplier 2 or a service consumer. Advantageously, the role of each actor makes it possible to define the access rights to the data and services; 30 - node "Information Technology Provider", commonly referred to as the "IT Provider": this node describes all the providers of the central data platform 4: providers 7 of user services and / or providers 11 basic services; 35 - "Client Account" node: this node describes the account of a customer who has subscribed to a set of services offered by the central data platform 4, or any user with 3031205 16 equipment 1 supporting services offered by the platform 4 data center. Figure 3 then describes the class diagram associated with the "Data" node previously described, that is, the classes inheriting from the "Data" node for classifying the different types of data. As can be seen in this diagram, a datum: - may comprise a unit of measurement, for example refer to a temperature or a pressure measured by a sensor. In addition, a physical quantity may be associated with a plurality of measurement units. By way of example, for a temperature measurement, it is possible to associate Celsius and Fahrenheit units; - A data may not include measurement, for example when it relates to a state (eg open or closed state of a door); A data item may be of the media type, for example text, an image or video. Data can moreover comprise a plurality of sources - "Sensor data": these data come from sensors, and are for example raw (untreated) data returned by the sensors, or a set of data aggregated according to a structure. predetermined (eg structured according to a pivot format), this set relating to measurements of at least one sensor; - "Environmental data": these are data that are not provided by the system 100. These data relate to a set of aggregated data of a predetermined geographical area (eg region, city) and may relate to examples of temperatures, pressures or particle levels; "Internet data" means "web data": this data may be text, image, video or any other multimedia support provided by a data provider 9. Figure 4 illustrates a class diagram describing the instances of the "Entity" node. With reference to this figure, in this topology model, a datum relating to the "Entity" class can be classified in one of the following instances ("subclasses"): - class "Being alive", comprising as possible instances O a "Person" class: as an example for e-Health services a person can be equipped with sensors to measure his voltage, temperature and have a connected device (eg watch) for the Transmitting said measurements associated with the sensors; o an "Animal" class: an animal may, for example, be equipped with a collar or an electronic chip making it possible to locate it; - "Place" class: any space provided with sensors, for example a business or a home; - "Object" class: generally any object placed in a physical space (eg office, home) using one or more sensors to measure a physical quantity or a state. For example, in a home, an object may be a refrigerator 15 equipped with a temperature sensor and transmitting / receiving means. Advantageously, a place may comprise a plurality of objects. Figure 5 is a topological diagram describing the different types of place and their compositions. The system 100 aims to 20 manage all the equipment 1 or connected objects deployed in different locations, said equipment 1 or objects being themselves arranged in specific areas and equipped with sensors. In this example, a place is either a business or a home. Thus, in this example, data relating to the "Location" class can be categorized in the "home" or "business" instances. The "Home" class includes here for instance the following classes: "Kitchen", "Dining room", "Stay", "Room", "Guest room", "Cellar", "Garden", "Garage". The "Enterprise" class can be implemented by the following 30 bodies: "Home", "Meeting Room", "Office", "Executive Office", "Open Area" commonly referred to as "Open Space" "," Technical Room "," Archive "," Sanitary ". It is understood that the modeling of these places is subsequently extensible according to the needs. Advantageously, the characteristics of the "Sensor" class introduced in FIG. 2 make it possible to provide data to 3031205 18 elementary service providers 11 for the development of reliable services. Commonly, a sensor can be described by the following characteristics: its measurement range: the extreme values that can be measured by the sensor; - its resolution: the smallest variation of measurable quantity by the sensor; its sensitivity: the variation of the output signal with respect to the variation of the input signal; Its accuracy: ability of the sensor to give a measurement close to the true value; - its speed: reaction time of the sensor; - its protocol: supported protocol, communication interface used.
[0009] Figure 6 illustrates a topological diagram for classifying a data pertaining to the "Sensor" class. In this figure, the class "Sensor" comprises for instances: - a class "physical magnitude sensor": this type of sensor makes it possible to measure a physical quantity such as a flow of water, 20 of gas, an electricity consumption, a value of temperature, pressure, or a humidity level; - A "state sensor" class: this type of sensor makes it possible to identify the state of an object, for example the state of a door (closed or open). Other examples include a presence sensor, or an image sensor. The "Actor" node of FIG. 2 comprises for instance the "Role" node, an actor of the system 100 that can combine different roles. Figure 7 illustrates the topological subset relating to this latter entity. Advantageously, the "Role" class includes the following instances: - "Data provider" class: a data provider 9 provides data that will be exploited by the services offered by the central data platform 4; - "Equipment Provider" class: an equipment supplier 2 35 provides hardware objects for the system 100 such as sensors, equipment 1, actuators; - "Service Provider" class: a user service provider 7 provides and exposes the user services on the central data platform 4; - "Service consumer" class: this instance refers to the 5 actors operating the services exposed by the central data platform 4. For example, an appliance manufacturer can use data from the central data platform 4 to adapt its offer. Furthermore, a user service provider 7 or equipment provider 2 can use services exposed by the central data platform 4. In this case, the actor is both a service / equipment provider and a service consumer; class "User": this instance designates a person, for example located in a home or company, having at least one box of communication type "Box". FIG. 8 is a topological diagram illustrating, according to the UML standard, the modeling of a service. In this figure the node 20 symbolizing the class "Service" is connected by stops to the following instances: "Supplier", "Consumer", "Interface", "Type of service". Advantageously, a service of the data management system 100 has the following characteristics: it is exposed (stops "supply by") by a provider (provider 7 of user services and / or providers 11 of basic services) on the platform 4 data center; - it is consumed (stops "offer by") by actors (eg customers, suppliers) of the data management system 100; It is associated with a predetermined interface. On the central data platform 4, in most cases, the service has (stop "dispose") a network interface; it is deployed on the central data platform 4, that is to say on the "Cloud", or deployed locally on the communication box 5. The place of deployment determines the type of service (stops "having").
[0010] Advantageously, the data management system 100 makes it possible to provide user services and to manage these services from their technical design to their deployment. To do this, the central data platform 4 offers basic services and sophisticated services, the latter being carried out via a fixed number of basic services. FIG. 9 illustrates the topological relationship existing between these various services, it distinguishes therefrom: - services of query type: these services relate to the 10 data. Advantageously, by querying through queries the database constituting the central data platform 4, it is possible to provide data to one or more actors of the system 100. By way of example, the data can be raw data relating to sensors or aggregated data; - Actuation services: these are services that use the actuators of equipment 1 to perform an action; notification services: these services perform a set of specific operations, based on the data stored in the central data platform. By way of examples, these services make it possible to carry out a diagnosis, or to recommend a scenario relating to equipment 1, in order to optimize the consumption of non-renewable energies such as electricity, gas, and water; - the services developed: these are services that are performed according to a predetermined sequence of workflows, commonly referred to as the "workflow". These services make it possible to carry out a set of operations by making common use of the basic services.
[0011] Advantageously, the set of previously described nodes, as well as their topological subsets, constitute a semantic data model. Based on this semantic model, the big data analytics analytics module 13 (or the central data platform 4), is configured to apply a processing on the data recorded in the central platform 4. For example, the analytic mega-data module 13 classifies, segments, aggregates, abstractes and / or formats any data of the central platform 4. For example, assuming that each data item includes a characteristic identifier of its origin, for example an identifier relating to the address of an internet network or a communication box, the analytic mega-data module 13 classifies according to these identifiers the raw or aggregated user data from the sensors, or the internet data provided by the data providers 9. Furthermore, the mega-data analytics module 13 optionally proceeds to this data at an abstraction / anonymization step, allowing to preserve their confidentiality, and then makes them accessible to the user service providers 7. Advantageously, the mega-data analytics module 13 provides services for different phases of use of the data stored in the central data platform 4. The following phases are distinguished: watch phase and trends: this phase makes it possible to identify trends by analyzing data from the internet and social networks. For this phase, the analytic mega-data module 13 provides data analysis tools and methods (eg Pig / Hive) for the user service providers 7. Advantageously, these tools enable the user service providers 7 to identify topics relating to the data recorded in the central data platform 4, and to develop statistical indicators with respect to these subjects. For example, the mega-data analytics module 13 conducts analysis on data from social networks or search engine queries, which data is provided by the data providers 9 to the central data platform 4. The result of the analysis performed by the mega-data analytics module 13 is then returned to the user service provider 7 in the form of keywords, enabling it to identify a relevant topic of current interest for the purpose of performing user services. ; service development phase: this phase allows the 35 user service providers 7 to develop services. To do this, the central data platform 4 provides reliable (possibly abstract) data, and the mega-data analytics module provides tools for the analysis of this data. According to various embodiments, the mega-data analytic module provides statistical tools based on data correlation methods, for example, Pearson correlations for continuous quantitative variables; ^ Spearman for ordinal data taking into account their ranks; 10 ^ Kendall for ordinal data taking into account their ranks; data analysis methods, such as Principal Component Analysis (PCA) methods for studying and visualizing correlations between several variables; Multiple Correspondence Analysis (MCA) methods for analyzing the linkage between qualitative variables; o methods of grouping data commonly referred to as "clustering". Advantageously, the reliable data to be analyzed / correlated by the analytic mega-data module 13 are made available to the various user service providers 7 via a reporting service (of the "reporting" type) and relate to 25 titles of examples, to sensor data, environmental data, or user data; deployment phase of a service: this phase allows different providers of user services to deploy their services in the data management system 100. For this phase, the mega-data analytics module 13 provides service provider 7 with service lifecycle management tools and control tools capable of providing prerequisites for the deployment of a client. service in the data management system 100; Service recommendation phase: this phase implements recommendation algorithms for recommending services to the actors of the data management system 100. For example, during this phase, basic services to user service providers 7, user services and / or user service usage scenarios to individuals are recommended. Advantageously, the recommendation services provided by the data management system 100 are based on collaborative filtering methods. Collaborative filtering is carried out, for example, by the analytic mega-data module 13 by applying a method able to compare the users with each other (eg type of service used, type of data consumed, user behavior), or elements previously noted (eg user services previously noted by their customers). In one embodiment, the data management system 100 proposes during this phase an equipment self-tuning service 1. To do this, the setting of a device 1 is stored for a predefined period in the central platform 4 of data, the setting is then applied to one or more other equipment 1 of the same type. In one embodiment, a "best scenario" service is provided by the data management system 100 to advocate or reproduce the best scenario for a user service, such as setting up a device or managing a device. a resource (eg water, gas, electricity). Advantageously, the recommendation of the best scenario is based on the result of an analysis conducted by the analytic mega-data module 13, this analysis being performed on information reported by equipment 1 of a similar category of users. To do this, we use clustering algorithms of the "k-means" or "canopy" type. For example, the setting up of the best scenario service is carried out via the following steps: o selection of the equipment 1 or the resource; o segmentation of users; o application of a "canopy" method to calculate a set of user clusters; 35 o application of a "k-means" method, in order to identify the best scenario for each cluster; 3031205 24 scoring phase: this phase allows you to assign a score and identify irrelevant services. The data management system 100, for example, proposes to customers to note the user services they use in an online shop, or to the user service providers 7 to note the basic services made available to them for carrying out the services. user services. Advantageously, such a phase makes it possible to anticipate the obsolescence of the services. To do this, the platform uses learning algorithms based on statistical methods, for example logistic regression methods or tree methods. Advantageously, in order to anticipate the obsolescence of the services, the megaadata analytics module 13 is configured to associate each service with a threshold, and to calculate a score relating to said service. If the service score is below the threshold, then the service then identified by the mega-data analytics module 13 as obsolete, the user service providers 7 are then notified. One of the challenges of the central data platform 4 relates to access (with segregation) to data and user services. The central data platform 4 indeed plays a pivotal role in the management and transmission of data with the communication boxes 5, the analytic mega-data module 13 ("Big Data Analytics") and the various actors / consumers of 25 data such as the providers 7 of user services. Thus, in one embodiment, the central data platform 4 is associated with equipment implementing the AAA protocol (Authentication, Authorization, Accounting), which performs authentication, authorization, and authentication functions. 30 traceability of data and services exposed by the central data platform. Advantageously, this makes it possible to guard against a data consumer accessing data or services to which he is not entitled or likely to derogate from the rules of private life. As examples, after authentication, a consumer is allowed to call a web service (commonly referred to as "web service") of the REST (Representational State Transfer) type or SOAP 3031205 ( acronym for "Simple Object Access Protocol"), or call a service a number of times per unit of time (eg a thousand times a month). The REST or SOAP service call makes it possible, in particular, to read the data coming from the equipment 1 or 5 of the 13 mega-data module, and makes it possible to send actions to the equipment 1. In addition, the central data platform 4 exposes one or more application programming interfaces called "API" (acronym for "Application Programming Interface"), and optionally a graphical user interface 10 called "GUI" (acronym for "Graphical User Interface"), allowing the provisioning of data of data consumers (customers, user service providers 7), data consuming applications, and to manage data access permissions, for example based on preconfigured roles and thresholds. Advantageously, the exposure of one or more API application programming interfaces by the central data platform 4 is dedicated to the providers and enables: - the basic service providers 11 to manage a set of services ("bundles") created by the various suppliers and deployed on the central data platform 4 (ex: validation of deployment, versions, pooling, statistics); - to the user service providers 7, consumers of 25 basic services and data, to access in an authenticated, controlled and counted way, through a front layer (eg website, mobile applications), to the information produced by the analytic module 13 mega-data ("Big Data Analytics"), after the latter module has processed (ex: 30 analyzed, correlated, grouped, formatted, abstract) the user data reported by the different boxes 5 communication. Likewise, a set of API application programming interfaces 35 dedicated to the end users is made available on each communication box 5. Advantageously, the exposure of one or more API application programming interfaces dedicated to the end-users, enables a front layer (eg: website, mobile applications) to offer the end-users of equipment 1, the purchase of online user services, for example via an on-line shop offered by an application; access to global information (eg statistical data) relating to the fleet of communication boxes, as well as to individual information per service purchased (access authenticated, controlled and accounted for); 10 - the setting of each user service (custom configuration); - access to rating and referral services for each service purchased. Advantageously, the integration of the data in the central data platform 4 is seen by the different entities as an intermediate layer, ensuring the transit of the information flows between: - the communication boxes 5, that is to say the information from the sensors of each equipment 1; A semantic base, such as the semantic data model previously described; - all services accessible to the final consumer constituting a service portal; the API application programming interfaces constituting a service management portal. Advantageously, such a portal facilitates automated interactions with the equipment 1 or information systems suppliers. In particular, in a multi-vendor context, the various devices (equipment 1, sensors, actuators) connected to a communication box 5 can come from different vendors, who do not have prior knowledge of each other, these devices being both supported by the communication box 5 and the central data platform 4. The central data platform 4 then trivializes the data coming from said devices, exposing them as services (eg action, alert, data), thus allowing the development of services relating to multiple devices and / or multiple vendors, these services 3031205 27 being subsequently deployed at the level of the central data platform 4 or the various communication boxes 5. Furthermore, the integration of the data into the central data platform 4 makes it possible subsequently to undertake a list of actions communicated by the central data platform 4 to at least one communication box 5, said box being connected to a fixed number of equipments 1. Advantageously, these actions are determined according to the semantic model, and are possibly related to: - equipment metrics data 1 reassembled by a communication box 5; a preconfigured action trigger event, for example, an action configured to be triggered at a predefined date or time; 15 - notifications pushed by API application programming interfaces exposed by the central platform 4 data, pushed for example through a web portal or a mobile application, relating to a user action request or supplier.
[0012] Thus, when receiving an event such as a notification or a metric, the central data platform 4 via a data integration layer: records in a history the event received if it is an event from a communication box 5.
[0013] The event may optionally contain parameters associated with a given equipment item 1; using the mega-data analytics module 13 classifies the event with the help of a semantic database, and establishes a correlation between this event and an associated service; If the service exists, sends data associated with the event to an execution mechanism (eg associated with the equipment 1), said mechanism being configured to generate an action associated with the service as well as the event ; pushes, via a push mechanism, the action generated towards the corresponding communication box. In addition, another issue of the central data platform 4 relates to its interfacing with the boxes 5 of 3031205 28 communication. The interface of the central data platform 4 with the communication boxes 5 must indeed manage the data flows: in the downstream direction: from the central data platform 5 to a communication box 5, for example when sending a command to a device 1 of the actuator type; in the uplink direction: from a communications box 5 to the central data platform 4, for example when a measurement originating from a sensor of an equipment item 1 is raised.
[0014] Currently, a communication box 5 is located in an "internal" local network (eg LAN) and connects to an "external" remote network (eg Internet) via an integrated access device, commonly referred to as the Integrated Access Device (IAD). The integrated access device IAD is provided by an Internet access provider and allows to exchange data streams of different types via a single connection. Thus, each previously described communication box 5 connects to the central data platform 4 behind an integrated access device IAD. In order to ensure communication between each communication box 5 and the central data platform 4, the integrated access device IAD establishes a connection with the central data platform 4. To establish this connection, the integrated access device IAD and the central data platform 4 have public addresses, while the communication box 5, located behind the integrated access device IAD, has a private address. , not addressable from the central data platform 4. Advantageously, such an architecture makes it possible for any communication box 5 located behind the integrated access device IAD to be able to initiate a data connection (uplink) to any broad internet platform while remaining protected. external threats. Thus, in the uplink direction, any communication box 5 arrives via the integrated access device IAD to reach the central data platform 4, for example during the feedback of measurements or events returned by sensors. . However, in the downward direction, for example for the management of actions to be sent to the equipment 1, the platform 4 central data 3031205 29 does not have means to reach the box 5 communication, because of its private addressing behind the IAD integrated access device. Furthermore, the communication box 5 may be temporarily unavailable from the point of view of the integrated access device IAD, for example in case of temporary disconnection or a simple electrical disconnection. Currently, any integrated access device IAD provides a network address translation rule function, commonly referred to as Network Address Translation (NAT), to map to a public address / output port. of the integrated access device IAD a private address / an input port relating to a communication box 5. Such a function is however not performed by default and requires for its activation the configuration of rules.
[0015] In addition, the development of mechanisms allowing the remote control (eg for administration) and the sending of action to equipment 1, connected to a communication box 5, from the central platform 4 data n ' is not implemented in the current architecture.
[0016] According to various embodiments, the remote control and the sending of action to one or more devices 1, connected to a communication box 5, from the central data platform 4, are implemented by the implementation of FIG. four mechanisms whose general operation is briefly recalled here: tunnel-type communication mechanism via proxy. Commonly, for this mechanism, a box-type communication box 5 establishes a connection via a transmission control protocol, hereinafter referred to as TCP, the acronym for Transmission Control Protocol.
[0017] This connection is established via the creation of a tunnel from the communication box 5 to a proxy server associated with a remote platform. Thus, in the embodiments developed later, a tunnel is established between a communication box 5 and a proxy disposed in the central data platform 4. The tunnel is then kept open by the communication box 5, for example via the sending dummy packets ("dummy packets"), or re-opened in case of 3031205 30 disconnection. The creation of this tunnel is carried out in the upstream direction, that is to say from the communication box 5 to the central data platform 4. The establishment of the tunnel then allows the flow of upstream or downstream information between the communication box 5 and the central data platform 4. Advantageously, thanks to the proxy, the central data platform 4 then sees the communication box 5, as if the integrated access device IAD was absent and implements a bi-directional data exchange mechanism. Such a mechanism nevertheless remains highly resource-consuming on the proxy servers by maintaining open TCP connections with the different communication boxes; communication mechanism based on the control protocol of "internet gateway device", hereinafter referred to as IGD protocol, acronym for "Internet Gateway Device Protocol". The IGD protocol is described in the UPnP (Universal Plug and Play) standard. Commonly the "boxes" of the operators, that is to say the integrated access devices IAD in this document, offer router-type functions, "firewall" ("firewall" in English) and "UPnP" . Some network applications, such as peer-to-peer P2P applications, sometimes offer when installing on a computer machine an automatic configuration option via the use of a "UPnP" type mechanism. The principle of this mechanism consists, via a UPnP controller present in the integrated access device IAD, to configure via the IGD protocol, a NAT "Network Address Translation" function of the fire. This configuration makes it possible in particular to establish a mapping between the public ports / public addresses of the IAD, and the private ports / private addresses of connected objects behind the firewall of the IAD. , and this in a manner transparent to the user. For example, the IGD protocol 35 establishes, via the NAT function, a correspondence between a private address and a private port to a communication box deployed in a local network, and a public address and a public port to the central platform 4. data deployed on the internet. Advantageously, the use of this mechanism then allows the central data platform 4 to then see the communication box 5, as if the integrated access device IAD was absent and proposes a bidirectional data exchange mechanism. This mechanism nevertheless presents risks of the security type: the reconfiguration of the firewall is potentially open to any third party software connected to the local network of the IAD, and once the "mapping" is set up, the communication box 5 is potentially exposed to the risk of attacks from the Internet. In addition, such a mechanism requires the support of the UPnP by the IAD and that this function is activated in the IAD; communication mechanism using the "extensible presence and messaging" protocol, hereinafter referred to as XMPP protocol, the acronym for Extensible Messaging and Presence Protocol. This messaging protocol is based on the TCP, XML protocols and replaces the Jabber protocol which is an instant messaging protocol. The XMPP protocol is described in specification TR-069. In particular, the appendix K.2 of version 1.4 of this specification (November 2013), describes a mechanism using the XMPP protocol to process via the NAT function, the problem of a connection request "Connection Request" destined for a "Subscriber Premises Equipment" commonly referred to as CPE, acronym for "Customer Premises Equipment". A CPE is, by way of example, the communication box 5 deployed in a local area network. For the sake of comprehension, this appendix is summarized here, additional details can be found therein: o an auto-configuration server ACS (acronym for "Auto-Configuration Server") establishes a connection with a server XMPP. The ACS auto-configuration server and the XMPP server are, for example, installed in an Internet network; o said self-configuration server ACS activates the use of the XMPP protocol at a CPE by the configuration of an XMPP object "XMPP Connection object", optionally providing a set of authorized Jabber identifiers; o said CPE establishes an XMPP (uplink) connection with the XMPP server; o When the ACS self-configuration server tries to communicate with the CPE, it sends an "XMPP Connection Request" message to the XMPP server. This message is an XMPP "stanza", commonly referred to as "XMPP IQ Stanza", and includes a "Connection Request" connection request indicating an authorized Jabber identifier for origin, referring to the ACS auto-configuration server. and indicating for destination an identifier relative to the CPE. O the XMPP server then transmits the message "XMPP IQ Stanza" to the appropriate CPE; o the CPE sends back an "lnform Request" message to the ACS auto-configuration server. In the embodiments described below, the ACS auto-configuration server is associated with the central data platform 4. Advantageously, this then makes it possible to implement an "alarm clock" type mechanism, making it possible to reduce the consumption of resources compared with the preceding mechanisms: any CPE, for example each box 5 of communication, is warned ("awakening") that it must contact the central data platform 4 with a rising stream in order to retrieve the downstream data stream. Advantageously, such a mechanism makes it possible to improve the security of the communication box 5; 30 - Communication mechanism based on the protocol "UDP simple traversal through NAT", hereinafter referred to as "STUN" protocol, acronym for "Simple Traversal of UDP through NATs". The STUN protocol allows an application of a CPE (eg the communication box 5) connected to an IAD behind a firewall to discover the possible presence of a function (ie a gateway). ) NAT of the IAD, and obtain the mapping ("mapping") of the application 3031205 33 with the public address and the UDP port (Anglicism of "User Datagram Protocol") of the integrated access device IAD allocated by the NAT gateway. The use of this protocol requires the assistance of a third party, namely a STUN server 5 deployed in a public network such as the Internet. The STUN protocol is described in the TR-111 specification ("Applying TR-069 to Remote Management of Home Networking Devices", December 2005). Notably, the "2.2 Procedures" portion of this specification describes the STUN protocol procedure for a CPE to receive a UDP connection request from a remote ACS auto-configuration server. The ACS auto-configuration server and the STUN server are deployed on the public address side of the NAT function of the integrated access device IAD. For the purpose of understanding, part 2 of the TR-111 specification is summarized here, additional details can be found therein: o the ACS auto-configuration server enables the use of the STUN protocol for the CPE (if this configuration is not enabled by default) and designates a STUN server to communicate with the CPE; o the CPE then uses the STUN protocol, to find out if it is behind a NAT gateway with an allocated private address; if so, the CPE uses the procedure defined by the STUN standard to discover the expiration of its data link behind the NAT gateway ("binding timeout"); o In order to perform the "mapping" step, the CPE periodically sends STUN link requests to the STUN server, called "STUN Binding 30 Requests". This makes it possible to keep the connection of the CPE open via the NAT gateway, this link enabling the CPE to listen for possible UDP connection requests ("UDP Connection Requests"); when the CPE determines the public IP address and the public port used for the link of the NAT gateway (used to listen for "UDP Connection Requests" messages), the CPE transfers the determined "mapping" information 3031205 to the ACS auto-configuration server, for example by sending a "STUN Binding Request" message; the ACS auto-configuration server then establishes a UDP connection with the CPE, by sending a UDP Connection Request UDP connection message to the port and the public address of the NAT gateway, determined by the CPE; In the embodiments described below, the ACS auto-configuration server and the STUN server are associated with the central data platform 4. Advantageously, this then makes it possible to implement an "alarm clock" type mechanism, making it possible to reduce the consumption of resources compared to the preceding mechanisms: any CPE, for example each communication box 15, is warned ("awakening") that it must contact the central data platform 4 with a rising stream in order to retrieve the downstream data stream. Advantageously, such a mechanism is rather resource-consuming on the central data platform 4. However, periodic sending of "STUN Binding request" requests that leave the NAT gateway open potentially exposes the CPE to external attacks. The table below lists the advantages and disadvantages of each of the previously introduced mechanisms: UPnP Tunnel XMPP STUN Securing High Low High Low Implementation Complex Complex Easy Complex Consumption High Low Medium Low Dependency DAI Low Medium Low Medium 25 Currently, mechanisms introduced above do not allow remote control (eg for administration) and sending action to equipment 1, connected to a communication box 5, from the central platform 4 data. Thus, after implementation, each of the mechanisms introduced above will be able to offer remote control, as well as the sending of action to equipment 1 connected to a communication box 5. According to various embodiments, during the deployment of the data management system 100, particularly the communication boxes, one or more of these four mechanisms are chosen according to the technical and operational constraints. Advantageously, a single mechanism is selected for each communication box 5 based, as examples, on the security level of the mechanism, its complexity of implementation, its resource consumption, and / or its level. dependence on the integrated access device IAD. This choice can, for example, rely on the table previously exposed. According to various embodiments, during the implementation of these mechanisms, ACS auto-configuration servers are then deployed, making it possible to manage the communication boxes and the initialization of the various mechanisms. With reference to FIG. 10, an abstraction layer is also implemented via a manager 14 of actions, integrated at the level of the central data platform 4, offering a unified interface, ie an independent interface. the type of mechanism implemented and therefore the protocol used by this mechanism. The abstraction layer, for example, is made using a method for formatting the data received / recorded by this layer 25 in a pivot format. Advantageously, the manager 14 is configured to manage (eg: receive, transmit, put on hold) the actions for the different devices 1. In FIG. 10, each communication box 5 uses a single mechanism of the type "tunnel via proxy" "," UPnP "," XMPP ", or" STUN ", selected during their deployment and in accordance with operational constraints. In addition, for each communication box 5, the selected mechanism is stored in the central data platform 4 via a database associated with the action manager 14. Advantageously, when receiving an action request 16 (eg an action pushed by an action consumer) to a destination 3031205 36 of a device 1 connected to a communication box 5, the action manager 14 is configured to: store the action received in the data base, thus allowing a temporary hold, the time that the communication box receives the action request. Standby is particularly advantageous when the communication box 5 is temporarily unavailable, for example during a loss of connection with the central data platform 4; o to process the action request 16, for example: identify the targeted equipment (identifier, address), identify the communication box to which it is connected, identify the communication mechanism to be used with said communication box 15 5 for transmit the action request. These different identifications are, for example, made by comparing the identifier of the equipment with a set of pre-recorded information in the database; 20 - trigger the action on the equipment 1 by transmitting the action request 16 to its communication box 5, via an appropriate communication mechanism, identified in the database 15. Moreover, as explained above, the mechanisms based on the XMPP and STUN protocols are of the "wake up" type: the communication box 5 is warned that it must contact the central data platform 4 by a rising flow in order to recover in return the downstream data flow. In order to support this mechanism, two components are then produced: a wake-up agent ("Wakeup Agent") made on the communication box 5 by setting up a middleware layer, commonly referred to as the Anglicism layer " middleware ". Advantageously, the production of such a layer allows any application of the communication box 5 to subscribe to a wake up service, allowing it to be woken by a central application; 3031205 37 - a wake-up server ("Wakeup Server") via the realization of a middleware layer on the central data platform 4, allowing any "consumer" action service (integrated or not on the central data platform 4) ) to wake up an application of the communication box 5. FIG. 11 illustrates the functional flow of data relating to an action consumer, such as a user service provider 7: the action consumer pushes (stream 18) an action request 16 to the manager 14; actions of the platform 4 10 central data. This request 16 action includes information on the type of action to be performed and the equipment 1 targeted by this action (eg equipment identifier, description of the action). This action request 16 may optionally be accompanied by a validity expiry date and an address, for example a "uniform resource locator" address, referred to as the URL, for notifying the reception and / or processing of the request. action request 16 by the communication box 5; the stock manager 14 stores (stream 19) queued in the database 15 this request and acknowledges (stream 20) the action request 16 issued to notify the consumer 17 of action that it it has been taken into account; from the identification of the targeted equipment 1, the actions manager identifies the communication box 5 and its corresponding access mechanism, then transmits the action request 16 to the communication box. The transmission of the action request 16 is a function of the type of communication mechanism, two situations that may occur o if the communication mechanism is of bidirectional type (of the "tunnel via proxy" or UPnP type): the manager 14 d The actions contacts the communication box 5 via the public address provided by the tunnel, or by the integrated access device IAD in the case of a UPnP mechanism; If, depending on the case, the tunnel is open or the UPnP configuration is performed, the action manager sends (stream 21) a request to the communication box to provide the action request 16. Otherwise, the action manager 14 waits for the re-establishment of the tunnel or UPnP reconfiguration to then send the action request 16, possibly managing the expiration dates of the action request 16; o if the mechanism is of "wake-up" type (STUN or XMPP) ^ the action manager 14 contacts the wake-up server ("Wakeup Server", middleware layer) of the central data platform 4; This wakeup server then attempts to wake communication box 5 by a low level protocol (in STUN or XMPP as the case may be). Advantageously, the content of the alarm message to the communication box 15 5 is limited, and may be limited to the type of alarm, for example: an alarm for action on the equipment 1 or an alarm clock for a remote grip In addition, this message is ideally related to a non-connected mode protocol, for example to the "user datagram protocol" referred to as UDP. The wake-up server also manages retransmission functions, because the communication box 5 is not necessarily accessible at the time of the removal of the action; Once the communication box 5 is accessible, the wake-up message reaches the wakeup agent of the latter, who is then in charge of analyzing the type of alarm and initiating the connection. to the central data platform 4 and to the right application to recover the pending actions; The central data platform 4 via its actions manager 35 provides (stream 21) then the pending requests for actions (including said action request 16) to the communication box 3031205. possibly managing the expiry date of each request; the communication box 5 then executes or transmits to the equipment 1 to which it is connected, the action request 16 5 and returns (stream 22) a report to the manager 14 of actions; o the share manager 14 (flow 23) then notifies the consumer 17 of shares, the proper execution of the action associated with his initial request (if specified at the initial request). Advantageously, the functional flow described above is unified, that is to say includes the same steps, whatever the mechanism considered. The operation of the said implemented mechanisms is now described for the following cases of figures: remote control of a device 1, sending of action to a device 1, measurement feedback of the sensor of a device 1 to the destination platform 4 central data. Figure 12 illustrates the main flows of a communication mechanism, to implement a tunnel between the communication box 5 and a proxy server 24. In this figure, a communication box 5 is interfaced with an integrated access device IAD, via a first communication port, the communication box 5 being only addressable via a private address located behind the integrated access device IAD. . The integrated access device IAD 25 has, moreover, a second communication port, allowing it to be addressable from an external network 26, for example an Internet network, via a public address. A central data platform 4 includes an action manager 14 associated with a database, as well as an ACS auto-configuration server 27 as described in specification TR-069. Moreover, for reasons of extensibility, the proxy server 24 is deployed in a proxy platform 28, able to exchange data with the central data platform 4. Advantageously, each communication box 5 being permanently connected to a proxy server 24, such an architecture allows a same proxy server 24 to manage a plurality of communications boxes 5 in a specific proxy platform 28. Each platform 28 proxy uses 3031205 it a fixed number of TCP connections with the platform 4 central data, this number being independent of the number of communication box 5 to which it is connected. To do this, it is possible to use multiplexing techniques.
[0018] Advantageously, such an architecture allows the 24 proxies servers to be seen from the central data platform 4, as virtual instances of the communication boxes 5, but deployed on a public network (eg Internet). Such a configuration is particularly advantageous because it makes it possible to overcome the problems concerning the addressing of the communication boxes in a private network. Furthermore, depending on the number of communication boxes 5, it is possible if necessary to add additional mandatory platforms 28, thereby participating in the extensibility of this architecture. The autoconfiguration server 15 ACS disposed in the central data platform 4 makes it possible to inform any communication box 5 during its initialization of the proxy server to which it is attached. The establishment of the tunnel between the communication box 5 and the proxy server 24 is now described. The establishment of this tunnel occurs at each initialization of the communication box 5 and comprises the following steps: - when it is initialized, the box 5 this communication is declared to the central data platform 4 via the server 27 of auto- ACS configuration according to the management protocol TR-069; the communication box 5 is then taken into account by the central data platform 4, and the latter chooses a proxy server 24 in order to establish a tunnel with the communication box 5, and associates it with the box 5 Communication. For example, the proxy server 24 is chosen by the central data platform 4, according to geographical proximity and availability; this association is transmitted to the server 27 of ACS auto-configuration; and then via a "SetParameterValues" message, the structure of which is defined in the protocol TR-069, the autoconfiguration server 27 ACS active in the communication box 5, the use of the tunnel by supplying it (stream 29). of FIG) the address of the proxy server 24; 3031205 41 - the communication box 5 establishes (flow 30 of the figure) then a TCP connection with the proxy server 24, and sends a message (non-standard) link "BIND" to indicate its identification. Advantageously, the "BIND" message comprises the identifier of the communication box 5, as well as the parameters of the TCP connection (ex: address and remote port, socket). Receipt of this message by the proxy server 24, will therefore allow the latter 24 to manage the virtual instance of the communication box 5, keeping for this instance 10 the identifier of the communication box 5, as well as the parameters of the TCP connection; this TCP connection is then kept permanently open by the communication box 5. FIG. 13 then illustrates, for the preceding architecture, the main data streams enabling remote handling of the communication box 5 and / or equipment 1: an external actor 31, such as a user service provider 7; sends (stream 32) a start request, for a communication box or a device 1, to the autoconfiguration server 27 ACS; the autoconfiguration server ACS 27 sends (stream 33) a connection request message "Connection Request", in accordance with the specification TR-069, to the proxy server 24, specifying in this message an identifier relative to the final recipient 25 of the grip, for example relating to a communication box 5 (or a device 1) targeted; thanks to the identifier of the communication box 5, the proxy server 24 then selects the virtual instance of the communication box 5, and therefore the corresponding tunnel 34; The proxy server 24 then transmits via the tunnel 34 corresponding the connection request "Connection Request" to the communication box 5 (stream 35); the communication box 5 then processes the request and transmits (stream 36) an "Inform request" message in accordance with the specification TR-069, to the autoconfiguration server 27 ACS, to notify it processing of the request; - the handling of the communication box 5 (or equipment 1), then follows the protocol TR-069, as any type of network topology with a CPE (here the box 5 communication).
[0019] FIG. 14 illustrates, for the same architecture, the main data streams making it possible to transmit an action request 16 to an actuator associated with a device 1: an external actor 37 such as an action consumer sends (stream 38) an action request to action manager 14 of the central data platform 4; - The stock manager 14 then stores said action request 16 in the database 15, then sends the action request 16 to the proxy server 24. To do this, the action manager 14 opens a TCP connection and is configured to send 15 (stream 39) two requests to the proxy server 24: o a first request, which is a (non-standard) connection request "CONNECT" , including the identification of the targeted communication box. Advantageously, the "CONNECT" message makes it possible to specify to the proxy server 24 that the following requests, namely the requests for action, must be addressed to the communication box 5; a second request corresponding to the action request 16, according to a syntax identical to the case of a communication box 5 directly visible from the Internet, for example a syntax http (s); advantageously, thanks to the connection request message "CONNECT" (first request), the proxy server 24 selects the virtual instance of the targeted communication box 5 and the corresponding tunnel 34. Advantageously, this realizes a temporary association within the proxy server, between the connection of the actions manager 14 to this server and the tunnel 34 of the communication box 5; the proxy server 24 then acknowledges the action manager 14 the good reception of the connection request message "CONNECT". As long as the action manager 14 does not receive this acknowledgment, for example when the tunnel 34 is not established, the action manager 14 is configured to re-issue this message periodically or wait for the tunnel 34 to be restored; when the acknowledgment of the "CONNECT" message is received by the action manager, the latter then transmits the second request, that is to say the action request to the proxy server; the proxy server sends (stream 40) then through the tunnel 34 the action request 16 as received to the targeted communication box 5; 10 - the communication box 5 then executes the requested action or else transmits it to the equipment 1 concerned for execution, then returns (flow 41) then a report to the proxy server 24 via the tunnel 34; the server 24 proxy transmits (stream 42) then the report as received to the manager 14 of actions; if requested, the share manager 14 then notifies (stream 43) the external actor 37 of the good execution of its initial action request by the communication box 5 or the equipment 1 concerned.
[0020] FIG. 15 illustrates, for the same mechanism, the main data flows making it possible to trace a measurement of a sensor associated with an item of equipment 1. In this figure, the central data platform 4 further comprises a manager 44. of measurements associated with a database 441 of data, making it possible to manage (store and / or make available) the data associated with the sensors of the different equipment 1. The process of measurement feedback to the central platform 4 of data from the sensor d 1 equipment connected to a communication box 5 is as follows: the communication box 5 retrieves the measurement from said sensor and transmitted by the equipment 1; the communication box 5 sends (stream 45) then to the proxy server 24, via the previously established tunnel 34, the measurement by a message indicating that the target is the measurement manager 44, for example by using a message of the "GET" type 35 http (s) "; the proxy server 24 then initiates a TCP connection to the measurement manager 44 and transmits (flow 46) the measurement.
[0021] FIG. 16 illustrates the main flows implemented for establishing a connection between the central data platform 4 and a communication box 5 for a communication mechanism implementing the UPnP protocol. As above: - the communication box 5 is interfaced with an integrated access device IAD, via a first communication port, the communication box 5 being only addressable via a private address; The integrated access device IAD has a second communication port, enabling it to be addressable from an external network, for example an internet network, via a public address; the central data platform 4 comprises an actions manager associated with a database 15 (not shown in this figure), as well as an ACS auto-configuration server 27 as described in the TR specification. -069. The following process is executed at each initialization of the communication box 5: at its initialization, the box 5 this communication is declared to the central data platform 4 by the ACS self-configuration server 27 via the management protocol TR-069; the communication box 5 is then taken into account by the central data platform 4, and the latter activates in the communication box the use of the UPnP protocol; the communication box 5 then sends UPnP requests to the integrated access device IAD, in order to open a public TCP communication port, thus enabling activation (stream 47) of the NAT network address translation function. ; The communication box 5 transmits (stream 48) then to the autoconfiguration server ACS 27, via the protocol TR-069, the public TCP port opened on the integrated access device IAD corresponding to the translation of NAT address to the box 5 communication.
[0022] FIG. 17 then illustrates, for the preceding mechanism, the main data streams, enabling remote handling of the communication box 5 and / or the devices 1: 3031205 - firstly an external actor 31 such as a provider 7 of user services sends (stream 49) a start request to the server 27 of ACS auto-configuration; the autoconfiguration server 27 ACS sends (stream 50) a "Connection Request" message, in accordance with the specification TR-069, to the communication box 5. To do this, it sends the "Connection Request" message to the public address of the integrated access device IAD, on the public TCP port opened during UPnP establishment. The integrated access device IAD 10 then transmits the message to the communication box 5 by applying the NAT network address translation function; - The communication box 5 then processes the order and sends (stream 51) back an "Inform request" message, in accordance with the TR-069 standard, to the server 27 of self-configuration 15 ACS to notify him the processing of the request; - The handling of the communication box 5 (or equipment 1), then follows the protocol TR-069, as any type of network topology with a CPE (here the box 5 communication).
[0023] FIG. 18 illustrates, for the same mechanism, the main data streams making it possible to transmit an action request to an actuator associated with a device 1: an external actor 37 such as a postal action consumer (stream 52); action request to the equity manager of the central data platform 4; the action manager 14 then stores said request in the database 15, then sends (stream 53) the request to the communication box 5. To do this, it sends the request to the public address of the integrated access device IAD on the public TCP port 30 open when the UPnP is established. The integrated access device IAD then transmits via the use of the NAT network address translation function the request to the communication box; - The communication box 5 then executes the requested action, 35 or otherwise transmits it to the equipment 1 concerned for execution, then returns (flow 54) then a report to the manager 14 actions. As long as the stock manager 14 does not receive this report, for example when the UPnP NAT function is not established, the action manager 14 is configured to periodically reissue this message or wait for the recovery of the message. NAT 5 UPnP network address translation function; if requested, the share manager 14 then notifies (stream 55) the external actor 37 of the proper execution of its initial action request by the communication box 5 or the equipment 1 concerned.
[0024] FIG. 19 illustrates, for the same mechanism, the main data flows making it possible to trace a measurement of a sensor associated with a device 1, to the central data platform measurements manager 4: the box 5 of FIG. communication retrieves the measurement from said sensor and transmitted by the equipment 1; the communication box 5 initiates (stream 56) then a connection, for example of the "http (s)" type, to the data manager 44 of the central data platform 4; the communication box 5 finally transmits the measurement by a message indicating that the target is the measurement manager 44, for example by using a message of the type "GET http (s)". FIG. 20 then illustrates the main flows implemented for establishing a connection between the central data platform 4 and a communication box 5 for a communication mechanism implementing the XMPP protocol. As above: - the communication box 5 is interfaced with an integrated access device IAD, via a first communication port, the communication box 5 being only addressable via a private address; the integrated access device IAD has a second communication port, enabling it to be addressable from an external network, for example an internet network, via a public address; the central data platform 4 comprises a share manager 14 associated with a data base, as well as an ACS auto-configuration server as described in the specification TR-069. Moreover, for reasons of extensibility, an http proxy server 57 and an XMPP proxy server 58, made in accordance with the TR-069 standard, are deployed in a proxy platform 28, the proxy platform 28 being able to exchange data. with the platform 4 central data. Advantageously, each communication box 5 is permanently connected to an XMPP proxy server 58. Advantageously, the realization of such an architecture allows a same XMPP proxy server 58 to manage a plurality of communications boxes in a specific proxy platform. As will be explained later, the HTTP proxy servers 57 will be used for the upload of measurements or the recovery of actions via http requests. Each proxy platform 28 uses a fixed number of connections with the central data platform 4, this number of connections being independent of the number of communication boxes to which it is connected. To do this, it is possible to use multiplexing techniques. Furthermore, depending on the number of communication boxes 5, it is possible, if necessary, to add additional proxy platforms, as well as proxy servers XMPP and servers 57 HTTP proxy, thereby participating in the extensibility of this architecture. The autoconfiguration server 27 ACS disposed in the central data platform 4 then makes it possible to inform any communication box 5 when it initializes the XMPP proxy server 58 to which it is attached. Similarly, during the configuration of the communication box 5, when it is started, the ACS self-configuration server 27 is in charge of informing the communication box 5 of its proxy proxy server 57.
[0025] The establishment of an XMPP connection between the communication box 5 and the XMPP proxy server 58 is now described. The establishment of this connection occurs at each initialization of the communication box 5 and comprises the following steps: during its initialization, the communication box 5 declares 35 to the central data platform 4 by the server 27 of auto-configuration ACS via the TR-069 management protocol; 3031205 48 - the communication box 5 is then taken into account by the central data platform 4, and the latter chooses a proxy proxy server XMPP 58, for example according to a geographical proximity and a server availability 58 proxy XMPP, and associates it with the communication box; this association is then transmitted to the server 27 for auto-configuration ACS; the auto-configuration server ACS 27 establishes (stream 59) then a connection with the XMPP proxy server 58, which will then be kept open by the autoconfiguration server 27 ACS; and then via the "SetParameterValues" message of the TR069 protocol, the ACS auto-configuration server 27 active in the communication box 5, the use of the XMPP protocol by supplying it (stream 60) with the address of the server, as well as the 15 authorized Jabber IDs. Advantageously, the authorized Jabber identifiers are declared identically in the XMPP proxy server 58 and the ACS auto-configuration server 27, and allow any XMPP client, for example the communication box 5, to identify itself during XMPP exchanges; 20 - the communication box 5 establishes (stream 61 of the figure) then an XMPP connection with the proxy server 58 XMPP, this connection will then be kept permanently open by the box 5 communication. FIG. 21 illustrates, for the architecture and the preceding mechanism, the main data flows enabling remote handling of the communication box 5 and / or equipment 1: first of all an external actor 31 such as a user service provider 7 sends (flow 62) a start-up request to the ACS auto-configuration server 27; The autoconfiguration server 27 ACS sends (stream 63), in accordance with Appendix K.2 of the specification TR-069, a connection request message "Connection Request" in XMPP ("stanza"). XMPP type "XMPP IQ Stanza") to the XMPP proxy server 58. The auto-configuration server ACS 27 specifies in this message the final recipient of the start-up, for example a targeted communication box, as well as the source of this message identified by an authorized Jabber identifier. The structure of such a message is particularly detailed in Appendix K.2.3.1 of specification TR-069; the XMPP proxy server 58 (stream 64) then transmits the message to the communication box 5 via the XMPP protocol; 5 - the communication box 5 then receives the message, and generates an XMPP response message ("XMPP Stanza" type XMPP stanza) of the "result" type if the previous message is correctly taken into account, or type "error" otherwise. The structures of these response messages are respectively detailed in Annex K.2.3.2 and K.2.3.3 of Specification TR-069; the communication box 5 then processes the request and transmits (stream 65) a "lnform request" message, in accordance with the specification TR-069, to the autoconfiguration server 27 ACS to notify it processing of the request; - The handling of the communication box 5 (or equipment 1), then follows the protocol TR-069, as any type of network topology with a CPE (here the box 5 communication).
[0026] FIG. 22 illustrates, for the same architecture and the same protocol, the main data streams making it possible to transmit an action request 16 to an actuator associated with a device 1: an external actor 37 such as an action consumer sends (stream 66) an action request 16 to the action manager 14 of the central data platform 4; the action manager 14 then stores said action request 16 in the database 15, then sends the action request 16 via an "Action Request" message in XMPP (message of the "XMPP IQ Stanza" type) to the XMPP proxy server 58.
[0027] Advantageously, the "Action Request" message comprises as origin an authorized Jabber identifier and as recipient the communication box 5. According to various embodiments, since the "Action Request" message is not described in specification TR-069, it is possible to draw inspiration from the structure of the "Connection Request" message described in appendix K.2.3.1 of this specification, to implement this message. An exemplary embodiment of the "Action Request" message is given below.
[0028] In this example, an action request 16 ("actionRequest" fields) of type "get", a Jabber identifier relating to the sender of the action request 16 (fields "from = ..." are specified in particular). Here, the action manager 14, a Jabber identifier for a recipient (fields "to = ...") of the action request 16, here the communication box 5, a message identifier (fields " id ") and connection information such as a user name and a password (fields" username "," password "), this information constituting a message 10 of the type" XMPP IQ Stanza "(fields" iq ): Iq from = "[PF-identity]" to = "L @ D / R" id = "cr001" type = "get"> <actionRequest xmlns = "urn: bull-org: cwmp: xmppActReq-1- 0 "> <username> username </ username> <password> password </ password> </ actionRequest> </ tg> - the XMPP proxy server 58, receives the" Action Request "message, and then acts as a wake up server ("Wakeup server"), in trans putting (stream 68) this message to the communication box 5 via the XMPP protocol. Furthermore, the XMPP proxy server 58 is capable of storing said message if the communication box 5 is disconnected, and then retransmitting it upon reconnection of the communication box 5; the communication box 5 then receives the message, and generates a response message in XMPP (XMPP stanza "XMPP 20 IQ Stanza") of the "result" type if the previous message is correctly taken into account, or of the "error" type " if not. The structures of these response messages are respectively detailed in Annex K.2.3.2 and K.2.3.3 of the TR069 specification; The communication box 5 then initiates an http (s) connection in order to retrieve the requests for pending actions. This connection is established (stream 69) with proxy server 57 of proxy platform 28, which itself will query (stream 70) the stock manager 14 for the purpose of retrieving stock requests, for example via a message of the type "GET http". Advantageously, the use of the proxy proxy server 57 in the proxy platform 28 then makes it possible to optimize the resources of the central data platform 4 by avoiding multiple http connections initiated directly from the different communication boxes; 5 - the action manager 14 then provides in response the action requests to the communication box 5, via the connection established with the proxy server XMPP 58. The action manager 14 also manages the expiry of the requests for actions in two modes: o in an asynchronous mode if the communication box 5 is not available, via the wake up message XMPP transmitted by the server 57 http proxy; according to a synchronous mode, by a "real-time" transmission of the actions to the communication box if it is available (subject to the temporal validity of the action, for example a function of a preconfigured time threshold); the communication box 5 then executes the requested action or else transmits it to the concerned device 1 for execution, then returns, via the http proxy server 57, a report to the action manager 14 ; if requested, the share manager 14 then notifies (stream 71) the external actor 37 of the good execution of its initial action request by the communication box 5 or the equipment 1 25 concerned. FIG. 23 again illustrates, for the same architecture, the main data flows making it possible to trace a measurement of a sensor associated with a piece of equipment 1. In this figure, the central data platform 4 comprises an associated measurement manager 44 a data base 441, for managing (storing and / or making available) the data associated with the sensors of the different equipment 1. The process of measurement feedback to the central data platform 4 from the sensor of an equipment 1 connected to a communication box 5 is the following: - the communication box 5 retrieves the measurement from said sensor and transmitted by the equipment 1; - the communication box 5 initiates (stream 72) an http (s) connection to the proxy proxy http server 57 of the platform 28; the http proxy server 57 then initiates an http (s) connection to the data management manager 44 of the central data platform 4; the communication box 5 sends (stream 73) then to the server 57 proxys http, via the established http (s) connection, the measurement by a message indicating that the target is the manager 44 of 10 measurements, for example by using a message of the type "GET http (s)". FIG. 24 illustrates the main flows implemented for the establishment of a tunnel, for a communication mechanism between the communication box 5 and the central data platform 4, for a communication mechanism implementing the STUN protocol. As above: - the communication box 5 is interfaced with an integrated access device IAD, via a first communication port, the communication box 5 being only addressable via a private address. This private address is, as an example, addressable via a gateway / NAT network address translation function constituting the integrated access device IAD; the integrated access device IAD has a second communication port, enabling it to be addressable from an external network 26, for example an internet network, via a public address; the central data platform 4 comprises an action manager 14 associated with a database 15 (not shown in this figure), as well as an ACS auto-configuration server 27 as described in the TR specification. -069. In addition, the central data platform 4 includes a STUN server 74, in accordance with the TR-111 specification. As explained below, such a server will establish a waking "tunnel" between the central data platform 4 and the communication box 5. The establishment of the connection between the communication box 5 and the central data platform 4 is now described. The establishment of this connection occurs at each initialization of the communication box 5 and comprises the following steps: when it is initialized, the communication box 5 declares itself to the central data platform 4 by the server 27 of automatic communication. ACS configuration via the TR-069 management protocol; the communication box 5 is then taken into account by the central data platform 4, and the latter activates in the communication box the use of the STUN protocol; The communication box 5 transmits (stream 75) STUN Binding Requests STUN link requests to the STUN server 74 of the central data platform 4, in accordance with part 2.2 of the TR-111 specification. The responses of the STUN server 74 to these requests then allow the communication box 5 to discover the public address of the integrated access device IAD. The communication box 5 transmits (stream 76) then the identified public address of the integrated access device IAD to the ACS self-configuration server 27 via the management protocol TR-069. Advantageously, the identification of the public address of the integrated access device IAD, allows the communication box 5 to discover the presence of a gateway / NAT function in the integrated access device IAD, and of establish through this gateway / function a UDP connection with the server 74 STUN 25 - in order to keep this connection open, the communication box 5 sends (stream 77) then periodically a STUN link request message of type " Binding Request ". Advantageously, this period is configured in such a way that the integrated access device IAD does not deactivate the NAT function after a period of inactivity, and is both long enough to avoid the saturation in resources of the device. 74 STUN server. Thus, in one embodiment, the communication box 5 performs a learning mechanism, initially transmitting connection request messages "Binding Request" with a low period, and then progressively increasing the transmission period 3031205 of these messages. This determines a limit period for which the box no longer receives a "Binding Response" connection response from the server 74 STUN. From this state, the period identified as usable by the communication box 5 is the period preceding this limit period. FIG. 25 illustrates, for the preceding mechanism, the main data flows enabling remote handling of the communication box 5 and / or equipment 1: first of all an external actor 31 such as a service provider 7 users sends (stream 78) a request to get in touch with the server 27 of ACS auto-configuration; the autoconfiguration server 27 ACS contacts (stream 79) the server 74 STUN, in accordance with the specification TR-111, and asks it to send a connection request message "Connection Request" according to the UDP protocol. , to the communication box 5. The realization of such a message is described in section 2.2.2.3 of this specification. The STUN server 74 is then the only element allowed by the integrated access device IAD to use the NAT network address translation function to the communication box. In fact, following the establishment of the connection with the STUN server 74, the integrated access device IAD knows only the address relating to the STUN server 74 and the UDP port used with this server; The STUN server 74 (stream 80) then transmits to the communication box 5 a UDP connection request message "Connection Request" to the public UDP port of the integrated access device IAD (used by the function / gateway of NAT network address translation to establish the connection with the communication box 5). The integrated access device IAD then transmits this message to the communication box 5 via the NAT network address translation gateway function / gateway; the communication box 5 then processes the command and sends back an "Inform request" message, in accordance with the standard TR-069, to the ACS auto-configuration server 27 (stream 81) to notify it the processing of the request; 3031205 - the handling of the communication box 5 (or equipment 1), then follows the protocol TR-069, as any type of network topology with a CPE (here the box 5 communication).
[0029] FIG. 26 illustrates, for the same mechanism, the main data streams making it possible to transmit an action request 16 to an actuator associated with a device 1: an external actor 37 such as an action consumer sends (stream 82) an action request to action manager 14 of the central data platform 4; the action manager 14 then stores said action request 16 in the database 15, then contacts the server 74 STUN (stream 83), in accordance with the specification TR111, and asks it to send a message " Action Request "in 15 UDP, to the communication box 5. According to various embodiments, the message "Action Request" is not described in the specification TR-111, we can be inspired by the structure of the message "Connection Request" described in section 2.2.2.3 of this specification, for implement this message. An exemplary embodiment of the "Action Request" message is given below. This specifies a non-empty path associated with the uniform resource identifier called "URI" of this message. To build this message, we add the highlighted path "ActionRequest", between a field of type "hostname", here "10.1.1.1:8080", and the arguments of this message specified after the " The STUN 74 server is then the only element allowed by the integrated access device IAD to use the function. This is the only one allowed by the IAD integrated access device 25 to use the function 74.1. NAT to the communication box 5. Indeed, following the establishment of the connection with the server 74 STUN, the integrated access device IAD only knows the address relative to the server 74 STUN as well as the UDP port used with this server; the server 74 STUN sends (stream 84) then to the communication box 5 a UDP action request message "Action 3031205 56 Request", to the public UDP port of the integrated access device IAD (used by the function / NAT network address translation gateway for establishing the connection with the communication box 5). The integrated access device IAD then transmits this message to the communication box 5 by applying the NAT network address translation function; the communication box 5 receives the message and sends an action response message, in accordance with the TR-111 standard, to the STUN server 74. Advantageously, the "Action Response" message is a UDP message made similarly to the "Action Request" message, via the use of a non-empty path. An example embodiment for this message is given below: http://10.1.1.1: 8080 / ActionReguest Ts = 1120673700 & id = 1234 & a = CPE57689 & cn = XTG RWIPC6D3IPXS3 & sig = 3545F7B5820076A3DF45A3A509DA8D8C38F13512 15 - As long as the 74 STUN server does not receive this response for "Action Response" acknowledgment, for example when the NAT UDP function is not established, the STUN server 74 is configured to periodically reissue the UDP message "Action Request" or wait for the restoration of the address translation function 20. NAT network; the communication box 5 then initiates (uplink) an http (s) connection to the stock manager (stream 85) in order to retrieve the requests for pending actions; the action manager 14 then provides in response the action requests to the communication box 5, while managing the expiry of the requests for actions according to two modes: o according to an asynchronous mode if the communication box 5 does not is not available, via a UDP wake-up message; according to a synchronous mode, by a "real-time" transmission of the actions to the communication box if it is available (subject to the temporal validity of the action, for example a function of the preconfigured time threshold); - the communication box 5 then executes the requested action or else transmits it to the relevant equipment 1 for execution, then returns a report to the action manager 14; if requested, the share manager 14 (stream 86) then informs the external actor 37 of the proper execution of its initial action request 16 by the communication box 5 or the equipment 1 concerned. In addition, for this architecture, the main data flows making it possible to trace a measurement of a sensor associated with a device 1, to the data center platform manager 4, are the same as those of FIG. describing these flows for a mechanism implementing the UPnP: the communication box 5 retrieves the measurement from said sensor and transmitted by the equipment 1; The communication box 5 initiates (stream 56) then a connection, for example of the "http (s)" type, to the data manager 44 of the central data platform 4; the communication box 5 finally transmits the measurement by a message indicating that the target is the manager 44 of 20 measurements, for example by using a message of the type "GET http (s)". The technical issues and embodiments of the communication box 5 are now described. As explained above, a communication box 5 (of the "box" type) is deployed in a specific environment or physical location, comprising one or more devices 1, each of these devices 1 offering user services. Advantageously, each communication box 5 serves: - a protocol gateway between the networks (wired or wireless) of local equipment 1, sensors, actuators and the central data platform 4, the latter accessible via an external network 26 from a device Integrated access IAD; - to the execution of services, when it is preferable to execute them locally rather than at the level of the central platform 4 data, for example for reasons of autonomy of the equipment 1.
[0030] The communication box 5 is moreover shared between several actors, for example equipment vendors 1 or user service providers 7. Therefore, the communication box 5 houses common and specific software components (notably the user services) to the said actors, making it possible to manage the communication with the different devices 1 or to perform a local data processing on the data coming from these devices 1 In this context, we often speak of "multi-tenant" architecture. The communication box 10 thus implements a middleware service platform. On this platform, the functions specific to each actor, for example the communication protocol used with a device 1 or the specific processing of data associated with a device 1, are deployed by the actors in the form of oriented software components. services. A failure or a diversion of a software component associated with an actor, therefore, must not impact and degrade the behaviors of the software components relating to the other actors hosted on the same platform. For example, a memory overflow resulting from a coding anomaly of a service must not propagate in the platform, under the risk of causing the "crash" of the other services. In addition, in the absence of standards, the equipment 1 connected to the communication box 5 is heterogeneous and based on different communication protocols. Thus, commonly a software component communicating initially with equipment 1 according to a protocol, will evolve when the equipment 1 changes because the associated protocol is also evolve. In addition, the change of a device 1 can also cause a modification of the access method of the communication box 5 to the data of the equipment 1. For example, the communication box 5 accesses the data initially. of an equipment 1 via a method of "pull" type: the equipment 1 exposes an application API programming interface and the communication box 5 takes the initiative to recover the measurements of a sensor associated with this equipment. change of this equipment 1 then leads to the use of a push access method: the data is pushed at the initiative of the equipment 1 to the communication box 5. As a result, the software component to communicate with this equipment must also evolve. Thus, to overcome its disadvantages is realized in the case 5 of communication, a software platform services based on the Java language and in accordance with the OSGi (acronym for "Open Services Gateway Initiative"), multi-tenant and integrating a unified API application programming interface for access to equipment 1 or connected services. Advantageously, such a software platform makes it possible to ensure: reliability and strong isolation between the software components of different users; an independence of the application services vis-à-vis the communication protocols with the equipment 1 or the data services; An independence of the application services with respect to the access methods (eg "pull", "push") to the equipment 1 or to the data services. Such a software platform is achieved by the aggregation of: - an access layer to connected equipment 1, the realization of which is described later; - a multi-tenant java platform providing isolation between services hosted by the platform. We can for this type of platform, rely on existing platforms of the state of the art. For example, a Java / OSGi platform based on a Haas model (hardware as a service) is implemented via application components placed in a shared container called "Kernel" and in separate and sealed containers. says "Features". Advantageously, such a platform is made so that the memory space allocated to each container is accessible only if it is configured to allow access. The access of an authorized user to a container, for example during the invocation of a method, is then performed through an API programming application interface, which limits the access of the user to the strict 35 necessary. It is thus impossible to use stack overflow techniques to circumvent the control and illicit access to the container's memory zone from the outside.
[0031] Advantageously, the container memory can not be accessed or corrupted from outside the container, the "Kernel" shared container and the "Features" sealed containers running within a Java 5 JVM virtual machine, and that it authorizes within it only the execution of isolated containers or communicating only through methods explicitly exposed and controlled. The programming code of the components of the "Kernel" is then considered reliable (with no anomalies), while the user services are grouped into separate "Features" specific to each provider. Advantageously, such a structure then guarantees a strong isolation between the user services, preventing any failure of one service having an impact on the others, ensures a management of the hardware resources (eg: memory occupancy, computing resources) by "Feature And limits the error propagation of any software component. Figure 27 illustrates the operating concept of a software platform 87 with the previously described features. The software platform 87 is a platform shared between several users, two in this example, and hosts the set of user services each relating to a device. In this example, a first service 88 refers to a first device 89, and a second service 90 relates to a second device 91. The first device 89 and the second device 91 are externally connected to the software platform 87 of the box 5 of communication, and use for their exchanges respectively a first and a second protocol. Furthermore, in another embodiment, any remote / remote service, accessible via an API application programming interface, can substitute for a device 89, 91. Here, by remote / distant service, any service allowing generalize a data source such as a device 89.91 or any service deployed in the "Cloud" type "software as a service" SaaS, acronym for "Software as a Service".
[0032] For example, the element 91 may be a remote service instead of the second device, this service using the second protocol. Advantageously, the specific software components 3031205 61 including the services 88, 90, specific to each user are respectively isolated in sealed containers 92, 93, commonly referred to as "sandbox" or "Feature". A unified API application programming interface 94 then makes it possible to access the devices 89, 91 or remote services from the services 88, 90 applications, or more generally to any external software or hardware element, called "eThing", connected to the software platform 87 of the communication box 5. Thus, to ensure both the support of elements (eg equipment 89, 91 or remote services) managed by a user, and the support of the communication protocols associated with these elements, it is deployed between the programming interface 94 a unified API application and any "eThing" element, a protocol protocol adapter of the element, as well as an element adapter, referred to as an "eThing" adapter, these adapters being in the form of software components, such as services; OSGi. Thus, in the illustrated example, a first and a second protocol adapter 95, 96 are respectively associated with the first and second devices 89, 91, each of these adapters being respectively interfaced with a first and a second adapter 97.98. eThing ", these adapters implementing the unified API application programming interface 94. Advantageously, the adapters specific to the same equipment are isolated in the same sealed container ("Feature"). For example, protocol adapters 95, 96 and eThing adapters 97, 98 are respectively deployed in the containers 92, 93. However, the same protocol adapter may possibly be shared among several users. Advantageously, the unified API application programming interface 94, the protocol adapters 95, 96 and the adapters 97, 98 of "eThing" elements 30 thus constitute a unified access structure ("framework"), that is, that is, an access layer to the connected equipment 1, 89, 91. FIG. 28 illustrates an example of the distribution of the elements of the software platform 87 previously described, combined with a Java / OSGi approach based on a Haas model (hardware as a service acronym) realized by application components arranged in a 100 shared container said "Kernel", and in 3031205 62 containers 101, 102 separate and sealed said "Features". In this example: the shared container "Kernel", reputedly reliable, embeds o interfaces 103 Java constituting the interface interface programming API unified API, detailed later, and data classes corresponding to the objects exchanged at the level of the application programming interface 94, for example structured data classes (eg binary, Boolean) raised by the equipment 1, 89, 91; protocol adapters 104 shared by all users, that is to say shared by different services, for example Zigbee adapters, or serial ports; common user services, for example a rules engine, and a data publishing service to a REST (Representational State Transfer) type interface; each container 101, 102 separate "Features" (software components), specific to a user, embeds 20 o services 106, 107 specific to a user, for example pretreatment services on the data of a device 1, 89, 91; protocol adapters 108, 109 specific to their equipment; O Adapters 110, 111 of "eThing" elements implementing the unified API application programming interface 94. Fig. 29 illustrates the realization of the unified access framework (framework) 99, comprising the unified API application programming interface. The latter is interfaced with an "eThing" element adapter via an interface designated hereafter as interface element 112 "eThing", this interface being an OSGi service. In this example, the "eThing" element adapter is the "eThing" element adapter 97 of the first equipment 89 (not shown). The element adapter 97 "eThing" is itself interfaced with the protocol adapter 95. The unified API 94 application programming interface, the "eThing" element adapter 97 and the protocol adapter 95 thus constitute the unified access structure 99. In this structure, each device 89, or more generally any connected element "eThing", is represented in the unified access structure 99 by an OSGi service 5 implementing the "eThing" element interface 112, this service comprising the attributes following: a state, a unique identifier, a name, a seller, a version, a serial number, a description. Thus, in the example below, an "eThing" element adapter 97 implements the OSGi "eThing" interface, is interfaced with a protocol adapter 95 via a "bindProtocolAdapter0" method, this method being able to associate any protocol adapter 95 with any "eThing" element, and includes for fields: a "Status" status, a unique "UID" identifier, a "NAME" name, a "VENDOR" seller, a "VERSION" version, a serial number 15 "SERIAL_NUMBER", a description "DESCRIPTION" package com.bull.everythink.etmfapi.ethings; import com.bull.everythink.etmf api. protocoladapters. ProtocolAdapter; public interface EThing {enum Status {UNRESOLVED, STOPPED, STARTED String PROPERTY NAME = "eThing.name"; String PROPERTY VENDOR = "eThing.vendor"; String PROPERTY VERSION = "eThing.Version String PROPERTY SERIAL_NUMBER =" eThing.seriaLnumber "; String PROPERTY DESCRIPTION =" eThing.description "; String PROPERTY UID =" eThing.uid "; Status getStatus (); void bindProtocolAdapter (ProtocolAdapter protocolAdapter); void unbindProtocolAdapter (); void starto; void stop (); String getUIDO;) The functions of the device 1, 89, 91 (or service) are represented by OSGi services implementing an interface 113 abstract function d elements named "eThingFunction" and three basic interfaces: an alarm interface called "Alarm", making it possible to generate the alarms from the equipment, these alarms being described by a class 115 named "AlarmData"; 3031205 A control interface 116 for controlling the state of a device and / or acting on it, and comprising two functions or a binary control function called "BinaryControl", s the case where the state associated with the sensor of a device is of binary type. The value of this state is then represented by a class named "BinaryData"; a multi-level control function 118 named "MultiLevelControl", in the case where the state of the sensor associated with a device comprises several states (multivalued). The value of this state is then represented by a class named "MultiLevelData"; a sensor interface 119 called "Sensor", making it possible to collect, periodically or not, a value derived from a sensor of a device 1, 89, 91, according to two functions: a bit sensor function 120 named " BinarySensor ", if the associated sensor is of binary type. The value is then represented by the class named "BinaryData"; o a multi-level sensor function 121 named "MultiLevelSensor", if the associated sensor case is multivalued. The value is then represented by the class named "MultiLevelData".
[0033] Exemplary embodiments of the eThingFunction element function abstract interface 113, the "Alarm" basic interface and the "AlarmData" class are given below: public interface EThingFunction <D extends Data> {String PROPERTY NAME = "eThing.function.name"; String PROPERTY DESCRIPTION = "eThing.function.description"; String TOPIC_DATA_PUBLISHED = "com / bullieverythinkletmfiethings / functionsidata / PUBLISHED"; Map <String, > GetPropertiesO; Class <D> supportedDataO; public interface Alarm <A extends AlarmData> extends EThingFunction <A> {) public class AlarmData implements Data {private long timestamp; 3031205 private Map <String, String> metadata = new HashMap <String, String> (); private int type; public AlarmDataant type, Map <String, String> metadata) {this (type, new DateagetTime (), metadata); ) public AlarmData (int type, long timestamp, Map <String, String> metadata) {this.timestamp = timestamp; this.type = type; if (metadata! = null) (this.metadata.putAll (metadata);) public int getType () (return type;) public Map <String, String> getMetadata () (return metadata;) public long getTimestamp () (return timestamp;) Advantageously, a new equipment 1, 89, 91 or added service is supported in the system by the addition of adapter 97 elements "eThing" via an "eThingAdapter" class implementing the 5 previously described interfaces. Thus, for communication with the first device 89, the element adapter 97 "eThing" is connected to the protocol adapter 95, the latter exposing a service with an OSGi interface adapted to the specific communication protocol of this equipment. Advantageously, the specific interfaces adapted to the communication protocols comprise two basic interfaces named "CommProtocolAdapter" and "ProtocolAdapterFactory". Each service of the "ProtocolAdapter" interface exposes at least the following two properties: type, vendor. Each type of protocol adapter 95 then defines an OSGi interface that extends the "CommProtocolAdapter" interface. Extending an interface (composed of associated methods, parameters and return values) here means taking over an existing interface at a more generic level of abstraction and adding new methods of its own. In addition, each protocol adapter is associated with a Protocol Adapter Factory (PAF), which makes it possible to create a protocol adapter with appropriate properties. Advantageously, each PAF protocol adapter factory defines an interface that extends the "ProtocolAdapterFactory" interface. The protocol adapter created by the PAF protocol adapter factory is then associated with an "eThing" element adapter. The "eThing" element adapter can then optionally notify the PAF protocol adapter factory that it no longer uses the protocol adapter, thereby freeing up any resources. An exemplary embodiment of protocol adapter 95, extending the OSGi "ProtocolAdapter" class, presenting for properties a "TYPE" type and a "VENDOR" vendor, is given below: package com.bull.everythink.etmfapi.protocoladapters; public interface ProtocolAdapter {String PROPERTY TYPE = "protocotadaptertype"; String PROPERTY VENDOR = "protocoladapter.vendor"; For this example, each protocol adapter is associated with a PAF protocol adapter factory, extending the "ProtocolAdapterFactory" interface and realized as follows: package com.bull.everythink.etmf.api.protocoladapters; import java.util.Dictionary; public interface ProtocolAdapterFactory {ProtocolAdapter createProtocolAdapter (Dictionary < , > properties) throws ProtocolAdapterException; void releaseProtocolAdapter (Protocol Adaptive protocolAdapter) throws ProtocolAdapterException; In addition, the unified access framework 99, more specifically the application programming interface 94, comprises the following two programmatic interfaces: a publication / subscription interface 122 called "publish / subscribe", allowing, according to an event mode o the asynchronous reception of events or data from a device 1, 89, 91 or a service, after a subscription / subscription step of the user, to the structure 99 ("framework ") Unified access (eg: to a specific service 88, 90); o asynchronous publishing from unified access framework (framework) 99 (eg from a specific service 3031205 67 88, 90), data or events to an equipment 1, 89, 91 or service one or more subscribed users; a request interface 123 called "request" allowing, in a synchronous mode, the retrieval, reading / writing of data from / to equipment 1, 89, 91 or service, to / from the structure 99 ("framework") unified access (ex: to / from a specific service 88, 90). Advantageously, the request interface 123 called "request" 10 makes it possible to send requests on the data reading equipment 1 (89, 91) "eThing" ("GET" type message) or write ( message of the type "SET" on an attribute or invocation of an operation). In one embodiment for creating queries to an element (equipment 1, 89, 91 or service), a static method is used, including for arguments the "uid" identifier of the "eThing" element, as well as the name of the "eThingFunction" element function. We then use a method to: - read the data on a device ("getData" command): <D extends Data> D getData (Class <D> rawDataType) 20 - write data to a device ("sendData" command): <D extends Data> Request sendData (D data) The publication / subscription interface 122 named "publish / subscribe", for its part, makes it possible: to produce data on this interface by informing an equipment identifier "eThing" : <D extends Data> Publisher publishData (D data, String eThingName, String eThingVersion, String eThingUid, String eThingFunctionName) Advantageously, this makes it possible to reinject data from an application service or higher level than the programming interface API 94 unified on this interface, for example, from a complex event processing engine CEP, acronym for "Complex Event Processing". Such a CEP engine can be both a consumer and a producer of data on the API application programming interface 94. In this example, the production of data results from the creation of a new event by the CEP engine (eg by correlation of other events), which data is then consumed by applications via the publication interface 122. subscription "publish / subscribe"; 5 - to subscribe to data produced on "eThings" elements, by defining an event filter called "EventFilter", making it possible to record an event "listener" on the service, commonly designated by the "listener" anglicism ". When data corresponding to the filter is published, a callback function is used, commonly referred to as "callback". Advantageously, the "callback" callback function makes it possible to implement an event interface 124 relating to the "eThing" element function called interface "EThingFunctionEvent" which has only one method: void handleEThingFunctionEvent (EThingFunctionEvent <D> event) An example of use of "listener", allowing a data consuming application of a device 1, 89, 91 to record a "callback" (or to invoke a method when its data will be available) is given below: 20 is given below: EventFilter eventFilter = EventFilter. eventFilter (context); MyHandler <Data> hdl = new MyHandler (...); eventFilter.registerEThingFunctionEventHandler (hdl, Data.class, getName (), getVersion (), getUid (), null); Advantageously, the set of user application services are based on the unified API application programming interface 94, allowing an abstraction of the devices 1, 89, 91 and the underlying communication protocols. Thus, the replacement of a device 1, 89, 91 by new equipment based on a different communication protocol, but offering the same services, ie the same functions, then has no impact. on the user service code linked to the unified API application programming interface 94. In addition, the unified API application programming interface 94 offers a means of abstracting the access mode to the devices 1, 89, 91 that it is synchronous (data mode pulled "pull") for reading or writing. data write, or asynchronous or event-related (push data mode) for reading data from equipment 1, 89, 91 via the publication interfaces 122, 123 subscription "publish / subscribe" and request "request". Advantageously, any mode not implemented natively by a device 1, 89, 91 is then simulated by the structure 99 ("framework") unified access. FIG. 30 illustrates, by way of example, a piece of equipment 1 operating in a synchronous mode (pull mode), interfaced with the unified access structure 99 including the programming interface 94. application unified API, this structure being interfaced with a first user service 125 based on synchronous mode, and a second user service 126 based on an asynchronous mode. The first user service 125 thus uses the request interface 123 "request", while the second service 126 user uses the publication / subscription interface "publish / subscribe" 122 of the API 94 application unified application programming interface. the unified access framework (framework) 99 In this example, the request modes emanating from the first user service 125 are represented by the arrow 127, while the publish / subscribe publication / subscribe modes are respectively represented by the arrows 128, 129. The synchronous mode "request" In writing and reading, is implemented by a simple delegation, that is to say by a simple method call, on the native interface of the equipment 1: we then use messages of the "SET" type in propagated write (arrow 130) on the device 1 and read "GET" returning the last value / data read on the device 1. The event mode being asynchronous, the latter mode is then simulated by the structure 99 ("framework") ) unified access 30 by periodically retrieving (arrow 131), via the request interface 123 "request", the data on the equipment and storing the last data read. The latter data is then sent to the publication / subscription interface "publish / subscribe" 122. Advantageously, the collection period is configurable via the "eThingFunction" element function abstract interface. FIG. 31 illustrates an equipment 1 operating in an event mode ("push" mode) interfaced with the unified 3031205 access framework (framework) 99 comprising the unified API application programming interface 94, this structure being interfaced with a first user service based on synchronous mode, and a second user service based on an asynchronous mode. The first user service 125 therefore uses the request interface 123 "request", while the second user service 126 uses the publication / subscription interface "publish / subscribe" of the unified API application programming interface 94. the unified access framework (framework) 99 In this example, the request modes from the first user service 125 are represented by the arrow 127, while the publication / subscription modes "publish / subscribe" are respectively represented by the arrows 128, 129. In the previous example, the equipment 1 pushes its data to the publication / subscription interface "publish / subscribe" 122. Thus, the arrow 128 relates to the propagation of the data that the equipment 1 pushes (arrow 132) at each new event. The equipment 1 being this time based on asynchronous mode, the structure 99 ("framework") unified access simulates this time the synchronous mode by storing the last data pushed by the equipment 20 1 via the interface 122 publication / subscription "publish / subscribe". This data is then sent to the request interface 123 "request". Then, as before, the synchronous mode "request" in writing and reading, is implemented by a simple delegation on the native interface of the equipment: one then uses messages of the type "SET" in propagated writing (arrow 130) on equipment 1 and read "GET" returning the last value read on the equipment 1.

权利要求:
Claims (5)
[0001]
REVENDICATIONS1. Apparatus data management system (100) (1), the system comprising - a central data platform (4) for interconnecting a plurality of communication boxes (5), each communication box interconnecting a plurality of devices (1) arranged locally in a predefined physical environment; and o being configured to go back to the central data platform (4) with data associated with said plurality of devices; an analyzer module (13) for mega-data configured to analyze the data recorded in the central data platform (4) so as to generate correlations, trends, and / or predictions; an interface (8) according to a service architecture oriented mode for the provision of the analysis results.
[0002]
The system of claim 1, further comprising an interface (12) in service architecture oriented mode for receiving data to the central data platform.
[0003]
3. The system of the preceding claim, wherein the data to the central data platform are derived from social networks. 25
[0004]
The system of any one of the preceding claims, wherein the mega-data analytics module (13) is further configured to classify, according to a predefined data topology, the data recorded in the platform (4). central data. 30
[0005]
The system of any one of the preceding claims, wherein the mega-data analytics module (13) is further configured to anonymize data stored in the central data platform (4) so as to preserve their confidentiality.

类似技术:

---

公开号 | 公开日 | 专利标题

---

EP3241121A1|2017-11-08|System for managing data of user devices

---

US20210218571A1|2021-07-15|Multi-services application gateway and system employing the same

---

Kleinfeld et al.2014|glue. things: a Mashup Platform for wiring the Internet of Things with the Internet of Services

---

Namiot et al.2014|On iot programming

---

Fazio et al.2014|The need of a hybrid storage approach for iot in paas cloud federation

---

Rahman et al.2020|A comprehensive survey on semantic interoperability for Internet of Things: State‐of‐the‐art and research challenges

---

Di Martino et al.2017|A semantic IoT framework to support RESTful devices' API interoperability

---

WO2016107996A1|2016-07-07|Box for communication and management of devices

---

EP3241308B1|2019-02-20|Interconnection box for user devices

---

EP3241316B1|2020-02-12|Method of communication between a remote action manager and a communication box

---

Simonis2008|OGC Sensor Web Enablement Architecture, Version: 0.4. 0.

---

FR3019340A1|2015-10-02|DETERMENIST RESPONSE ELECTRONIC COMPONENT

---

FR3038479A1|2017-01-06|METHOD FOR DISCOVERING THE CONFIGURATION OF A DOMOTIC INSTALLATION

---

EP3817294A1|2021-05-05|Method and module for a connectivity regulation of connected objects.

---

Rachidi2011|Design and implementation of a framework for self-configuring devices using TR-069

---

Gopikrishnan et al.2019|Web-Based IoT Application Development

---

FR3082028A1|2019-12-06|AGGREGATION OF CONNECTED OBJECTS.

---

Rodrigues2013|Large scale interoperability in the context of Future Internet

---

FR3076022A1|2019-06-28|VIRTUALIZATION OF A CONNECTED OBJECT

---

Dmitry et al.2014|On iot programming

---

FR3109253A1|2021-10-15|Communication scheduling process and Communication device for connected objects

---

Evensen2013|Event processing applied to streams of TV channel zaps and sensor middleware with virtualization

---

Singh2017|Testing Internet of Things Data Management | Middleware

---

FR3017505A1|2015-08-14|METHODS OF CONTROLLING AND PROPOSING CONTROL OF EQUIPMENT CONNECTED TO A COMMUNICATION NETWORK, EQUIPMENT, SYSTEM, COMPUTER PROGRAM PRODUCTS AND CORRESPONDING DATA CARRIERS

---

Sun et al.2014|Handbook of Research on Demand-Driven Web Services: Theory, Technologies, and

同族专利:

---

公开号 | 公开日

---

WO2016107999A1|2016-07-07|

---

EP3241121A1|2017-11-08|

---

FR3031205B1|2017-01-27|

---

US20180191858A1|2018-07-05|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

US20140275807A1|2013-03-15|2014-09-18|I2Dx, Inc.|Electronic delivery of information in personalized medicine|

---

US8078431B2|1992-11-17|2011-12-13|Health Hero Network, Inc.|Home power management system|

---

IL152824A|2002-11-13|2012-05-31|Mosaid Technologies Inc|Addressable outlet and a network using same|

---

US20090070168A1|2007-09-07|2009-03-12|Power Measurement Ltd.|Enterprise energy management system with social network approach to data analysis|

---

US8649987B2|2008-05-07|2014-02-11|PowerHouse dynamics, Inc.|System and method to monitor and manage performance of appliances|

---

US20110113360A1|2009-11-12|2011-05-12|Bank Of America Corporation|Facility monitoring and control system interface|

---

US8811397B2|2010-02-16|2014-08-19|Ncp Engineering Gmbh|System and method for data communication between a user terminal and a gateway via a network node|

---

SG191407A1|2011-01-04|2013-08-30|Zik Energy Points Inc|Method and system for energy efficiency and sustainability management|

---

EP2686643A4|2011-03-18|2014-09-10|Soneter Llc|Methods and apparatus for fluid flow measurement|

---

US20120260263A1|2011-04-11|2012-10-11|Analytics Intelligence Limited|Method, system and program for data delivering using chatbot|

---

US10216485B2|2011-09-19|2019-02-26|Tata Consultancy Services Limited|Computer platform for development and deployment of sensor data based applications and services|

---

CN106104414B|2013-11-13|2019-05-21|Twc专利信托公司|Storage equipment and the method for storing and providing data|JP2017191508A|2016-04-14|2017-10-19|富士通株式会社|Information processing device and connection information setting program|

---

US10567302B2|2016-06-01|2020-02-18|At&T Intellectual Property I, L.P.|Enterprise business mobile dashboard|

---

FR3053194A1|2016-06-22|2017-12-29|Orange|METHOD AND DEVICE FOR PROVIDING AN ADDRESS BY A DEVICE MANAGING A NETWORK|

---

WO2018183375A1|2017-03-29|2018-10-04|MobileIron, Inc.|Correlating mobile device and app usage with cloud service usage to provide security|

---

EP3537682A1|2018-03-07|2019-09-11|ABB Schweiz AG|Method for automatic configuration of sematic-based projects in building automation systems|

法律状态:
2015-11-23| PLFP| Fee payment|Year of fee payment: 2 |

---

2016-07-01| PLSC| Publication of the preliminary search report|Effective date: 20160701 |

---

2016-11-21| PLFP| Fee payment|Year of fee payment: 3 |

---

2017-11-21| PLFP| Fee payment|Year of fee payment: 4 |

---

2019-12-23| PLFP| Fee payment|Year of fee payment: 6 |

---

2020-12-29| PLFP| Fee payment|Year of fee payment: 7 |

---

2021-12-15| PLFP| Fee payment|Year of fee payment: 8 |

优先权:

---

申请号 | 申请日 | 专利标题

---

FR1463496A|FR3031205B1|2014-12-31|2014-12-31|UTILIZER EQUIPMENT DATA MANAGEMENT SYSTEM|FR1463496A| FR3031205B1|2014-12-31|2014-12-31|UTILIZER EQUIPMENT DATA MANAGEMENT SYSTEM|

---

US15/541,189| US20180191858A1|2014-12-31|2015-12-07|System for managing data of user devices|

---

PCT/FR2015/053351| WO2016107999A1|2014-12-31|2015-12-07|System for managing data of user devices|

---

EP15810700.3A| EP3241121A1|2014-12-31|2015-12-07|System for managing data of user devices|